From herbert@gondor.apana.org.au Tue Jun 1 05:26:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 05:26:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51CQFgi031236 for ; Tue, 1 Jun 2004 05:26: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 1BV8LC-0007jA-00; Tue, 01 Jun 2004 22:26:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BV8L9-00059K-00; Tue, 01 Jun 2004 22:25:59 +1000 Date: Tue, 1 Jun 2004 22:25:59 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Fix xfrm_tunnel leak Message-ID: <20040601122559.GA19761@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5515 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 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I recently managed to create a mode=tunnel state that I couldn't get rid of: 192.168.0.6 192.168.0.178 unspec mode=tunnel spi=3232235526(0xc0a80006) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=mature created: May 29 13:20:10 2004 current: Jun 1 22:23:15 2004 diff: 291785(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=19776 refcnt=0 Turns out that the IPIP tunnel used by IPCOMP states are only freed if the IPCOMP state is deleted by xfrm_state_delete. This is not the case for all states. For example, an immature IPCOMP state that dies in add_sa will not go through xfrm_state_delete. The following patch moves the delete_tunnel call into IPCOMP's destructor. I think it makes more sense there as IPCOMP is the only user of the tunnel anyway. 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 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ipcomp.c 1.19 vs edited ===== --- 1.19/net/ipv4/ipcomp.c 2004-04-17 06:54:43 +10:00 +++ edited/net/ipv4/ipcomp.c 2004-06-01 22:21:02 +10:00 @@ -339,6 +339,7 @@ struct ipcomp_data *ipcd = x->data; if (!ipcd) return; + xfrm_state_delete_tunnel(x); ipcomp_free_data(ipcd); kfree(ipcd); } ===== net/xfrm/xfrm_state.c 1.44 vs edited ===== --- 1.44/net/xfrm/xfrm_state.c 2004-05-30 18:20:34 +10:00 +++ edited/net/xfrm/xfrm_state.c 2004-06-01 22:18:09 +10:00 @@ -231,7 +231,6 @@ void xfrm_state_delete(struct xfrm_state *x) { - xfrm_state_delete_tunnel(x); spin_lock_bh(&x->lock); __xfrm_state_delete(x); spin_unlock_bh(&x->lock); --UugvWAfsgieZRqgk-- From margitsw@t-online.de Tue Jun 1 08:46:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 08:46:11 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51Fk7gi006616 for ; Tue, 1 Jun 2004 08:46:08 -0700 Received: from fwd08.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1BUWdP-0006Jx-00; Sun, 30 May 2004 22:10:19 +0200 Received: from margit.t-online.de (TJ+RCBZAZenhvOVdrTt86V8tPLyzw4zj-lx7EhfiyPRDdZsSCLqfck@[80.128.220.231]) by fwd08.sul.t-online.com with esmtp id 1BUWd9-087UY40; Sun, 30 May 2004 22:10:03 +0200 Message-Id: <5.1.0.14.2.20040530215351.0c1f6cb8@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 May 2004 22:04:21 +0200 To: netdev@oss.sgi.com From: margitsw@t-online.de (Margit Schubert-While) Subject: [PATCH 14/17 linux-2.6.7-rc2] prism54: Reduce module verbosity Cc: jgarzik@pobox.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_50528325==_" X-Seen: false X-ID: TJ+RCBZAZenhvOVdrTt86V8tPLyzw4zj-lx7EhfiyPRDdZsSCLqfck X-archive-position: 5516 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 --=====================_50528325==_ Content-Type: text/plain; charset="us-ascii"; format=flowed 2004-05-01 Margit Schubert-While * Reduce module verbosity --=====================_50528325==_ Content-Type: application/octet-stream; name="14-reduce-verbosity.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="14-reduce-verbosity.patch" ZGlmZiAtTmF1ckViQiBsaW51eC0yLjYuNmN0L2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNtNTQv aXNscGNpX2Rldi5jIGxpbnV4LTIuNi42LTAxL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNtNTQv aXNscGNpX2Rldi5jCi0tLSBsaW51eC0yLjYuNmN0L2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNt NTQvaXNscGNpX2Rldi5jCTIwMDQtMDUtMjggMTU6NDg6MzQuMTU2MTEyMDMyICswMjAwCisrKyBs aW51eC0yLjYuNi0wMS9kcml2ZXJzL25ldC93aXJlbGVzcy9wcmlzbTU0L2lzbHBjaV9kZXYuYwky MDA0LTA1LTI4IDE1OjQ3OjUyLjkxNzM4MTI3MiArMDIwMApAQCAtNjksNyArNjksOSBAQAogCWlm IChyZWcgJiBJU0wzOFhYX0NUUkxfU1RBVF9TTEVFUE1PREUpCiAJCS8qIGRldmljZSBpcyBpbiBz bGVlcCBtb2RlLCBJUlEgd2FzIGdlbmVyYXRlZCBieSBzb21lb25lIGVsc2UgKi8KIAl7Ci0JCXBy aW50ayhLRVJOX0RFQlVHICJBc3N1bWluZyBzb21lb25lIGVsc2UgY2FsbGVkIHRoZSBJUlFcbiIp OworI2lmIFZFUkJPU0UgPiBTSE9XX0VSUk9SX01FU1NBR0VTCisJCURFQlVHKFNIT1dfVFJBQ0lO RywgIkFzc3VtaW5nIHNvbWVvbmUgZWxzZSBjYWxsZWQgdGhlIElSUVxuIik7CisjZW5kaWYKIAkJ cmV0dXJuIElSUV9OT05FOwogCX0KIAo= --=====================_50528325==_-- From shemminger@osdl.org Tue Jun 1 09:15:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 09:15:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51GFQgi007971 for ; Tue, 1 Jun 2004 09:15:26 -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 i51GDrr12390; Tue, 1 Jun 2004 09:13:53 -0700 Date: Tue, 1 Jun 2004 09:13:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Herbert Xu , debian.bugs@kepier.clara.net, 251215@bugs.debian.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Bug#251215: kernel-image-2.6.6-1-k7: pppd locks up, cannot be killed, during ppp shutdown Message-Id: <20040601091353.53275685@dell_ss3.pdx.osdl.net> In-Reply-To: <20040529124833.5eca66d7.davem@redhat.com> References: <20040528124355.GA2391@gondor.apana.org.au> <40B744DC.9956BF50@kepier.clara.net> <20040529051736.GA11303@gondor.apana.org.au> <20040529124833.5eca66d7.davem@redhat.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: 5518 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: 1030 Lines: 33 On Sat, 29 May 2004 12:48:33 -0700 "David S. Miller" wrote: > On Sat, 29 May 2004 15:17:36 +1000 > Herbert Xu wrote: > > > Why do we need to call free_netdev after unregistering the netdev > > from the drivers at all? What's wrong with calling it from run_todo > > itself? > > Because the driver is the only agent which knows when it is safe > to free up the structure. It may still have some attached memory > to free, for example, ala: > > unregister_netdev(dev); > kfree(dev->priv); > free_netdev(dev); > > This is common, for example in drivers/net/tg3.c:tg3_remove_one() we > have: > > struct tg3 *tp = netdev_priv(dev); > > unregister_netdev(dev); > iounmap((void *)tp->regs); > free_netdev(dev); > Also, for those device that don't want to do anything in between: dev->destructor = free_netdev; Will end up calling free_netdev in the run_todo processing. This can be very handy when unregister needs to happen in some context already called with RTNL. From bogdan.costescu@iwr.uni-heidelberg.de Tue Jun 1 09:49:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 09:49:12 -0700 (PDT) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51Gn7gi008972 for ; Tue, 1 Jun 2004 09:49:08 -0700 Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i51Gmv1K022929; Tue, 1 Jun 2004 18:48:57 +0200 (MET DST) Received: from kenzo.iwr.uni-heidelberg.de (IDENT:qun9XNNMwSAhVLnStO7X4a//H7LYsWpP@kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.12.10/8.12.9) with ESMTP id i51GmvrT009382; Tue, 1 Jun 2004 18:48:57 +0200 (MET DST) Received: from kenzo.iwr.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8) with ESMTP id i51GmvCL005416; Tue, 1 Jun 2004 18:48:57 +0200 Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8/Submit) with ESMTP id i51Gmvnh005412; Tue, 1 Jun 2004 18:48:57 +0200 Date: Tue, 1 Jun 2004 18:48:57 +0200 (CEST) From: Bogdan Costescu To: netdev@oss.sgi.com cc: Andrew Morton Subject: [3c59x] Add support for ATI Radeon 9100 IGP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: netdev Content-Length: 1936 Lines: 58 Hi! [ I don't know if Andrew (3c59x maintainer) still reads the vortex mailing list where I just posted the same patch, so I thought mentioning it on netdev as well would be a good idea. ] The patch adds support for the 3Com networking core found in the ATI Radeon 9100 IGP southbridge used on boards like Asus P4R800-VM. The patch is against the 3c59x driver from 2.6.6; it should apply cleanly to most other 2.6 versions and applies with some offsets also for 2.4.2x. A bit of discussion about the patch can be found on the vortex list archives, like: http://marc.theaimsgroup.com/?l=linux-vortex&m=108610754614149&w=2 --- linux-2.6.6-orig/drivers/net/3c59x.c 2004-05-10 04:31:55.000000000 +0200 +++ linux-2.6.6/drivers/net/3c59x.c 2004-05-25 23:45:29.000000000 +0200 @@ -446,6 +446,7 @@ CH_3C905B_2, CH_3C905B_FX, CH_3C905C, + CH_3C9202, CH_3C980, CH_3C9805, @@ -521,6 +522,8 @@ PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, }, {"3c905C Tornado", PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM, 128, }, + {"3C920B-EMB-WNM (ATI Radeon 9100 IGP)", + PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_MII|HAS_HWCKSM, 128, }, {"3c980 Cyclone", PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, }, {"3c980C Python-T", @@ -597,6 +600,7 @@ { 0x10B7, 0x9058, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_2 }, { 0x10B7, 0x905A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_FX }, { 0x10B7, 0x9200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905C }, + { 0x10B7, 0x9202, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C9202 }, { 0x10B7, 0x9800, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C980 }, { 0x10B7, 0x9805, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C9805 }, -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From davem@redhat.com Tue Jun 1 12:37:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 12:37:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51Jakgi027783 for ; Tue, 1 Jun 2004 12:37: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 i51Jaci5030123; Tue, 1 Jun 2004 15:36:38 -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 i51Jab029371; Tue, 1 Jun 2004 15:36:37 -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 i51JaT4o003403; Tue, 1 Jun 2004 15:36:29 -0400 Date: Tue, 1 Jun 2004 12:35:42 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Fix xfrm_tunnel leak Message-Id: <20040601123542.48e364e4.davem@redhat.com> In-Reply-To: <20040601122559.GA19761@gondor.apana.org.au> References: <20040601122559.GA19761@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5520 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: 566 Lines: 16 On Tue, 1 Jun 2004 22:25:59 +1000 Herbert Xu wrote: > Turns out that the IPIP tunnel used by IPCOMP states are only freed > if the IPCOMP state is deleted by xfrm_state_delete. > > This is not the case for all states. For example, an immature IPCOMP > state that dies in add_sa will not go through xfrm_state_delete. > > The following patch moves the delete_tunnel call into IPCOMP's > destructor. I think it makes more sense there as IPCOMP is the > only user of the tunnel anyway. Looks perfect, patch applied. Thanks Herbert. From margitsw@t-online.de Tue Jun 1 13:12:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 13:12:08 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51KC0gi028855 for ; Tue, 1 Jun 2004 13:12:04 -0700 Received: from fwd05.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1BUWbx-0003M4-00; Sun, 30 May 2004 22:08:49 +0200 Received: from margit.t-online.de (G59megZdQeSfVxZnmpeOox8UHYhYJc0-Z0sDLziBHT3YhthnJdiU6e@[80.128.220.231]) by fwd05.sul.t-online.com with esmtp id 1BUWbn-1HmenI0; Sun, 30 May 2004 22:08:39 +0200 Message-Id: <5.1.0.14.2.20040530213959.00b07890@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 May 2004 22:03:21 +0200 To: netdev@oss.sgi.com From: margitsw@t-online.de (Margit Schubert-While) Subject: [PATCH 7/17 linux-2.6.7-rc2] prism54: Fix endian patch Cc: jgarzik@pobox.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_50441250==_" X-Seen: false X-ID: G59megZdQeSfVxZnmpeOox8UHYhYJc0-Z0sDLziBHT3YhthnJdiU6e X-archive-position: 5521 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: 3570 Lines: 54 --=====================_50441250==_ Content-Type: text/plain; charset="us-ascii"; format=flowed * Split out patch islpci_eth.c : * Fix endian problem (bug 74/75 related) --=====================_50441250==_ Content-Type: application/octet-stream; name="07-fix-endian.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="07-fix-endian.patch" ZGlmZiAtTmF1ckViIGxpbnV4LTIuNi42Y3QvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJpc201NC9p c2xwY2lfZXRoLmMgbGludXgtMi42LjYtMDEvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJpc201NC9p c2xwY2lfZXRoLmMKLS0tIGxpbnV4LTIuNi42Y3QvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJpc201 NC9pc2xwY2lfZXRoLmMJMjAwNC0wNS0yOCAxNDo0MDoyNi45OTY0NTQ3NDQgKzAyMDAKKysrIGxp bnV4LTIuNi42LTAxL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNtNTQvaXNscGNpX2V0aC5jCTIw MDQtMDUtMjggMTQ6MjU6MzAuMDY1ODA4OTI4ICswMjAwCkBAIC0yNjIsOSArMjYyLDkgQEAKIAlp ZiAocHJpdi0+bmRldi0+dHlwZSA9PSBBUlBIUkRfSUVFRTgwMjExX1BSSVNNKSB7CiAJCXN0cnVj dCBhdnNfODAyMTFfMV9oZWFkZXIgKmF2czsKIAkJLyogZXh0cmFjdCB0aGUgcmVsZXZhbnQgZGF0 YSBmcm9tIHRoZSBoZWFkZXIgKi8KLQkJdTMyIGNsb2NrID0gaGRyLT5jbG9jazsKKwkJdTMyIGNs b2NrID0gbGUzMl90b19jcHUoaGRyLT5jbG9jayk7CiAJCXU4IHJhdGUgPSBoZHItPnJhdGU7Ci0J CXUxNiBmcmVxID0gYmUxNl90b19jcHUoaGRyLT5mcmVxKTsKKwkJdTE2IGZyZXEgPSBsZTE2X3Rv X2NwdShoZHItPmZyZXEpOwogCQl1OCByc3NpID0gaGRyLT5yc3NpOwogCiAJCXNrYl9wdWxsKCpz a2IsIHNpemVvZiAoc3RydWN0IHJmbW9uX2hlYWRlcikpOwpAQCAtMjg4LDIwICsyODgsMjAgQEAK IAkJCQkJCQkgICBzaXplb2YgKHN0cnVjdAogCQkJCQkJCQkgICBhdnNfODAyMTFfMV9oZWFkZXIp KTsKIAotCQlhdnMtPnZlcnNpb24gPSBodG9ubChQODAyMTFDQVBUVVJFX1ZFUlNJT04pOwotCQlh dnMtPmxlbmd0aCA9IGh0b25sKHNpemVvZiAoc3RydWN0IGF2c184MDIxMV8xX2hlYWRlcikpOwot CQlhdnMtPm1hY3RpbWUgPSBfX2NwdV90b19iZTY0KGNsb2NrKTsKLQkJYXZzLT5ob3N0dGltZSA9 IF9fY3B1X3RvX2JlNjQoamlmZmllcyk7Ci0JCWF2cy0+cGh5dHlwZSA9IGh0b25sKDYpOwkvKk9G RE06IDYgZm9yIChnKSwgOCBmb3IgKGEpICovCi0JCWF2cy0+Y2hhbm5lbCA9IGh0b25sKGNoYW5u ZWxfb2ZfZnJlcShmcmVxKSk7Ci0JCWF2cy0+ZGF0YXJhdGUgPSBodG9ubChyYXRlICogNSk7Ci0J CWF2cy0+YW50ZW5uYSA9IGh0b25sKDApOwkvKnVua25vd24gKi8KLQkJYXZzLT5wcmlvcml0eSA9 IGh0b25sKDApOwkvKnVua25vd24gKi8KLQkJYXZzLT5zc2lfdHlwZSA9IGh0b25sKDIpOwkvKjI6 IGRCbSwgMzogcmF3IFJTU0kgKi8KLQkJYXZzLT5zc2lfc2lnbmFsID0gaHRvbmwocnNzaSk7Ci0J CWF2cy0+c3NpX25vaXNlID0gaHRvbmwocHJpdi0+bG9jYWxfaXdzdGF0aXN0aWNzLnF1YWwubm9p c2UpOwkvKmJldHRlciB0aGFuICd1bmRlZmluZWQnLCBJIGFzc3VtZSAqLwotCQlhdnMtPnByZWFt YmxlID0gaHRvbmwoMCk7CS8qdW5rbm93biAqLwotCQlhdnMtPmVuY29kaW5nID0gaHRvbmwoMCk7 CS8qdW5rbm93biAqLworCQlhdnMtPnZlcnNpb24gPSBjcHVfdG9fYmUzMihQODAyMTFDQVBUVVJF X1ZFUlNJT04pOworCQlhdnMtPmxlbmd0aCA9IGNwdV90b19iZTMyKHNpemVvZiAoc3RydWN0IGF2 c184MDIxMV8xX2hlYWRlcikpOworCQlhdnMtPm1hY3RpbWUgPSBjcHVfdG9fYmU2NChsZTY0X3Rv X2NwdShjbG9jaykpOworCQlhdnMtPmhvc3R0aW1lID0gY3B1X3RvX2JlNjQoamlmZmllcyk7CisJ CWF2cy0+cGh5dHlwZSA9IGNwdV90b19iZTMyKDYpOwkvKk9GRE06IDYgZm9yIChnKSwgOCBmb3Ig KGEpICovCisJCWF2cy0+Y2hhbm5lbCA9IGNwdV90b19iZTMyKGNoYW5uZWxfb2ZfZnJlcShmcmVx KSk7CisJCWF2cy0+ZGF0YXJhdGUgPSBjcHVfdG9fYmUzMihyYXRlICogNSk7CisJCWF2cy0+YW50 ZW5uYSA9IGNwdV90b19iZTMyKDApOwkvKnVua25vd24gKi8KKwkJYXZzLT5wcmlvcml0eSA9IGNw dV90b19iZTMyKDApOwkvKnVua25vd24gKi8KKwkJYXZzLT5zc2lfdHlwZSA9IGNwdV90b19iZTMy KDMpOwkvKjI6IGRCbSwgMzogcmF3IFJTU0kgKi8KKwkJYXZzLT5zc2lfc2lnbmFsID0gY3B1X3Rv X2JlMzIocnNzaSAmIDB4N2YpOworCQlhdnMtPnNzaV9ub2lzZSA9IGNwdV90b19iZTMyKHByaXYt PmxvY2FsX2l3c3RhdGlzdGljcy5xdWFsLm5vaXNlKTsJLypiZXR0ZXIgdGhhbiAndW5kZWZpbmVk JywgSSBhc3N1bWUgKi8KKwkJYXZzLT5wcmVhbWJsZSA9IGNwdV90b19iZTMyKDApOwkvKnVua25v d24gKi8KKwkJYXZzLT5lbmNvZGluZyA9IGNwdV90b19iZTMyKDApOwkvKnVua25vd24gKi8KIAl9 IGVsc2UKIAkJc2tiX3B1bGwoKnNrYiwgc2l6ZW9mIChzdHJ1Y3QgcmZtb25faGVhZGVyKSk7CiAK --=====================_50441250==_-- From ebs@ebshome.net Tue Jun 1 13:17:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 13:17:34 -0700 (PDT) Received: from gate.ebshome.net (gate.ebshome.net [66.92.248.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51KHTgi029252 for ; Tue, 1 Jun 2004 13:17:32 -0700 Received: (qmail 19060 invoked by uid 1000); 1 Jun 2004 13:17:24 -0700 Date: Tue, 1 Jun 2004 13:17:24 -0700 From: Eugene Surovegin To: Herbert Xu Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [IPSEC] fix ref counting in __xfrm4_bundle_create() Message-ID: <20040601201724.GA17412@gate.ebshome.net> Mail-Followup-To: Herbert Xu , netdev@oss.sgi.com, davem@redhat.com References: <20040529001450.GA647@gate.ebshome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ICQ-UIN: 1193073 X-Operating-System: Linux i686 User-Agent: Mutt/1.5.5.1i X-archive-position: 5522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebs@ebshome.net Precedence: bulk X-list: netdev Content-Length: 310 Lines: 9 On Sat, May 29, 2004 at 01:27:13PM +1000, Herbert Xu wrote: > However, can you see if the following patch fixes this problem as well? > It moves the dst->xfrm assignment to a spot where errors cannot occur. Yes, your version is OK. We haven't got the crash during our testing. Thanks a lot, Herbert. Eugene From dlstevens@us.ibm.com Tue Jun 1 13:19:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 13:19:27 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51KJNgi029576 for ; Tue, 1 Jun 2004 13:19:25 -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.2) with ESMTP id i51KJ6Y0642848; Tue, 1 Jun 2004 16:19:07 -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 i51KJ65n195444; Tue, 1 Jun 2004 14:19:06 -0600 In-Reply-To: <20040531151843.7144dfce.akpm@osdl.org> To: Andrew Morton Cc: netdev@oss.sgi.com, Russell Leighton MIME-Version: 1.0 Subject: Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 1 Jun 2004 14:19:04 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/01/2004 14:19:06, Serialize complete at 06/01/2004 14:19:06 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 5523 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: 1008 Lines: 21 > In the udp case, I when I listen for multicast packets my app only > receives them when I am running a tcpdump (bizarre!). Russ, This piece (which I expect has nothing to do with the other problems you mentioned) sounds like you haven't joined the groups on the interface on which you're receiving the multicast packets. "tcpdump" will place the interface in "promiscuous mode" which will receive all packets, and ordinary packet delivery will allow the application to receive them, even if you haven't joined the group on the relevant interface. To verify if the group joins is broken, you can look at /proc/net/igmp. If the groups you're joining are not listed on the interface you want, the program isn't joining the groups correctly. Group membership is per-interface, so joining a group on one interface does not join it on another. Feel free to contact me if you need some help debugging the multicast problem. +-DLS From margitsw@t-online.de Tue Jun 1 13:45:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 13:45:06 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51Kj1gi030513 for ; Tue, 1 Jun 2004 13:45:02 -0700 Received: from fwd01.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1BUWcn-0000uN-09; Sun, 30 May 2004 22:09:41 +0200 Received: from margit.t-online.de (Xdua3BZLZewH9yNGwCyVKv-O4YQ+XIYJCDQwCblzaeWfpo4P4ZvxoF@[80.128.220.231]) by fwd01.sul.t-online.com with esmtp id 1BUWck-0pdcQa0; Sun, 30 May 2004 22:09:38 +0200 Message-Id: <5.1.0.14.2.20040530215003.00b1f4d0@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 May 2004 22:00:09 +0200 To: netdev@oss.sgi.com From: margitsw@t-online.de (Margit Schubert-While) Subject: [PATCH 12/17 linux-2.6.7-rc2] prism54: Add likely/unlikely, KO wds completely Cc: jgarzik@pobox.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_50498543==_" X-Seen: false X-ID: Xdua3BZLZewH9yNGwCyVKv-O4YQ+XIYJCDQwCblzaeWfpo4P4ZvxoF X-archive-position: 5524 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: 7424 Lines: 107 --=====================_50498543==_ Content-Type: text/plain; charset="us-ascii"; format=flowed 2004-04-26 Margit Schubert-While * islpci_mgt.h : Replace init_wds with a define. The compiler does not optimize it out (and also generates the field in the ro section of every module) * prismcompat.h : Include linux/compiler.h Now we can play with the likely/unlikely macros --=====================_50498543==_ Content-Type: application/octet-stream; name="12-add-likely.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="12-add-likely.patch" ZGlmZiAtTmF1ckViQiBsaW51eC0yLjYuNmN0L2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNtNTQv aXNsX2lvY3RsLmMgbGludXgtMi42LjYtMDEvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJpc201NC9p c2xfaW9jdGwuYwotLS0gbGludXgtMi42LjZjdC9kcml2ZXJzL25ldC93aXJlbGVzcy9wcmlzbTU0 L2lzbF9pb2N0bC5jCTIwMDQtMDUtMjggMTU6MTQ6NDkuNDE4OTE4ODcyICswMjAwCisrKyBsaW51 eC0yLjYuNi0wMS9kcml2ZXJzL25ldC93aXJlbGVzcy9wcmlzbTU0L2lzbF9pb2N0bC5jCTIwMDQt MDUtMjggMTU6MzM6NDIuMTg0NzEyMjk2ICswMjAwCkBAIC0yMTUyLDcgKzIxNDYsNyBAQAogCXtQ UklTTTU0X0RCR19PSUQsIElXX1BSSVZfVFlQRV9JTlQgfCBJV19QUklWX1NJWkVfRklYRUQgfCAx LCAwLAogCSAiZGJnX29pZCJ9LAogCXtQUklTTTU0X0RCR19HRVRfT0lELCAwLCBJV19QUklWX1RZ UEVfQllURSB8IDI1NiwgImRiZ19nZXRfb2lkIn0sCi0Je1BSSVNNNTRfREJHX1NFVF9PSUQsIElX X1BSSVZfVFlQRV9CWVRFIHwgMjU2LCAwLCAiZGJnX2dldF9vaWQifSwKKwl7UFJJU001NF9EQkdf U0VUX09JRCwgSVdfUFJJVl9UWVBFX0JZVEUgfCAyNTYsIDAsICJkYmdfc2V0X29pZCJ9LAogCS8q IC0tLSBzdWItaW9jdGxzIGhhbmRsZXJzIC0tLSAqLwogCXtQUklTTTU0X0dFVF9PSUQsCiAJIDAs IElXX1BSSVZfVFlQRV9DSEFSIHwgSVdfUFJJVl9TSVpFX0ZJWEVEIHwgUFJJVl9TVFJfU0laRSwg IiJ9LApkaWZmIC1OYXVyRWJCIGxpbnV4LTIuNi42Y3QvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJp c201NC9pc2xwY2lfZXRoLmMgbGludXgtMi42LjYtMDEvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJp c201NC9pc2xwY2lfZXRoLmMKLS0tIGxpbnV4LTIuNi42Y3QvZHJpdmVycy9uZXQvd2lyZWxlc3Mv cHJpc201NC9pc2xwY2lfZXRoLmMJMjAwNC0wNS0yOCAxNDo0MTozMi44MjA0NDc5NzYgKzAyMDAK KysrIGxpbnV4LTIuNi42LTAxL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNtNTQvaXNscGNpX2V0 aC5jCTIwMDQtMDUtMjggMTU6MzM6NDIuMTg3NzExODQwICswMjAwCkBAIC0xMDUsNyArMTA1LDcg QEAKIAogCS8qIGNoZWNrIHdoZXRoZXIgdGhlIGRlc3RpbmF0aW9uIHF1ZXVlIGhhcyBlbm91Z2gg ZnJhZ21lbnRzIGZvciB0aGUgZnJhbWUgKi8KIAljdXJyX2ZyYWcgPSBsZTMyX3RvX2NwdShjYi0+ ZHJpdmVyX2N1cnJfZnJhZ1tJU0wzOFhYX0NCX1RYX0RBVEFfTFFdKTsKLQlpZiAoY3Vycl9mcmFn IC0gcHJpdi0+ZnJlZV9kYXRhX3R4ID49IElTTDM4WFhfQ0JfVFhfUVNJWkUpIHsKKwlpZiAodW5s aWtlbHkoY3Vycl9mcmFnIC0gcHJpdi0+ZnJlZV9kYXRhX3R4ID49IElTTDM4WFhfQ0JfVFhfUVNJ WkUpKSB7CiAJCXByaW50ayhLRVJOX0VSUiAiJXM6IHRyYW5zbWl0IGRldmljZSBxdWV1ZSBmdWxs IHdoZW4gYXdha2VcbiIsCiAJCSAgICAgICBuZGV2LT5uYW1lKTsKIAkJbmV0aWZfc3RvcF9xdWV1 ZShuZGV2KTsKQEAgLTEyMSw3ICsxMjEsNyBAQAogCS8qIENoZWNrIGFsaWdubWVudCBhbmQgV0RT IGZyYW1lIGZvcm1hdHRpbmcuIFRoZSBzdGFydCBvZiB0aGUgcGFja2V0IHNob3VsZAogCSAqIGJl IGFsaWduZWQgb24gYSA0LWJ5dGUgYm91bmRhcnkuIElmIFdEUyBpcyBlbmFibGVkIGFkZCBhbm90 aGVyIDYgYnl0ZXMKIAkgKiBhbmQgYWRkIFdEUyBhZGRyZXNzIGluZm9ybWF0aW9uICovCi0JaWYg KCgobG9uZykgc2tiLT5kYXRhICYgMHgwMykgfCBpbml0X3dkcykgeworCWlmICh1bmxpa2VseSgo KGxvbmcpIHNrYi0+ZGF0YSAmIDB4MDMpIHwgaW5pdF93ZHMpKSB7CiAJCS8qIGdldCB0aGUgbnVt YmVyIG9mIGJ5dGVzIHRvIGFkZCBhbmQgcmUtYWxsaWduICovCiAJCW9mZnNldCA9ICg0IC0gKGxv bmcpIHNrYi0+ZGF0YSkgJiAweDAzOwogCQlvZmZzZXQgKz0gaW5pdF93ZHMgPyA2IDogMDsKQEAg LTE5Miw3ICsxOTIsNyBAQAogCXBjaV9tYXBfYWRkcmVzcyA9IHBjaV9tYXBfc2luZ2xlKHByaXYt PnBkZXYsCiAJCQkJCSAodm9pZCAqKSBza2ItPmRhdGEsIHNrYi0+bGVuLAogCQkJCQkgUENJX0RN QV9UT0RFVklDRSk7Ci0JaWYgKHBjaV9tYXBfYWRkcmVzcyA9PSAwKSB7CisJaWYgKHVubGlrZWx5 KHBjaV9tYXBfYWRkcmVzcyA9PSAwKSkgewogCQlwcmludGsoS0VSTl9XQVJOSU5HICIlczogY2Fu bm90IG1hcCBidWZmZXIgdG8gUENJXG4iLAogCQkgICAgICAgbmRldi0+bmFtZSk7CiAKQEAgLTM4 MiwxMCArMzgyLDEwIEBACiAJc2tiLT5kZXYgPSBuZGV2OwogCiAJLyogdGFrZSBjYXJlIG9mIG1v bml0b3IgbW9kZSBhbmQgc3B5IG1vbml0b3JpbmcuICovCi0JaWYgKHByaXYtPml3X21vZGUgPT0g SVdfTU9ERV9NT05JVE9SKQorCWlmICh1bmxpa2VseShwcml2LT5pd19tb2RlID09IElXX01PREVf TU9OSVRPUikpCiAJCWRpc2NhcmQgPSBpc2xwY2lfbW9uaXRvcl9yeChwcml2LCAmc2tiKTsKIAll bHNlIHsKLQkJaWYgKHNrYi0+ZGF0YVsyICogRVRIX0FMRU5dID09IDApIHsKKwkJaWYgKHVubGlr ZWx5KHNrYi0+ZGF0YVsyICogRVRIX0FMRU5dID09IDApKSB7CiAJCQkvKiBUaGUgcGFja2V0IGhh cyBhIHJ4X2FubmV4LiBSZWFkIGl0IGZvciBzcHkgbW9uaXRvcmluZywgVGhlbgogCQkJICogcmVt b3ZlIGl0LCB3aGlsZSBrZWVwaW5nIHRoZSAyIGxlYWRpbmcgTUFDIGFkZHIuCiAJCQkgKi8KQEAg LTQxOCw3ICs0MTgsNyBAQAogCSAgICAgc2tiLT5kYXRhWzBdLCBza2ItPmRhdGFbMV0sIHNrYi0+ ZGF0YVsyXSwgc2tiLT5kYXRhWzNdLAogCSAgICAgc2tiLT5kYXRhWzRdLCBza2ItPmRhdGFbNV0p OwogI2VuZGlmCi0JaWYgKGRpc2NhcmQpIHsKKwlpZiAodW5saWtlbHkoZGlzY2FyZCkpIHsKIAkJ ZGV2X2tmcmVlX3NrYihza2IpOwogCQlza2IgPSBOVUxMOwogCX0gZWxzZQpAQCAtNDM0LDcgKzQz NCw4IEBACiAJICAgICAgIGluZGV4IC0gcHJpdi0+ZnJlZV9kYXRhX3J4IDwgSVNMMzhYWF9DQl9S WF9RU0laRSkgewogCQkvKiBhbGxvY2F0ZSBhbiBza19idWZmIGZvciByZWNlaXZlZCBkYXRhIGZy YW1lcyBzdG9yYWdlCiAJCSAqIGluY2x1ZGUgYW55IHJlcXVpcmVkIGFsbGlnbm1lbnQgb3BlcmF0 aW9ucyAqLwotCQlpZiAoc2tiID0gZGV2X2FsbG9jX3NrYihNQVhfRlJBR01FTlRfU0laRV9SWCAr IDIpLCBza2IgPT0gTlVMTCkgeworCQlza2IgPSBkZXZfYWxsb2Nfc2tiKE1BWF9GUkFHTUVOVF9T SVpFX1JYICsgMik7CisJCWlmICh1bmxpa2VseShza2IgPT0gTlVMTCkpIHsKIAkJCS8qIGVycm9y IGFsbG9jYXRpbmcgYW4gc2tfYnVmZiBzdHJ1Y3R1cmUgZWxlbWVudHMgKi8KIAkJCURFQlVHKFNI T1dfRVJST1JfTUVTU0FHRVMsICJFcnJvciBhbGxvY2F0aW5nIHNrYiBcbiIpOwogCQkJYnJlYWs7 CkBAIC00NTQsNyArNDU1LDcgQEAKIAkJICAgIHBjaV9tYXBfc2luZ2xlKHByaXYtPnBkZXYsICh2 b2lkICopIHNrYi0+ZGF0YSwKIAkJCQkgICBNQVhfRlJBR01FTlRfU0laRV9SWCArIDIsCiAJCQkJ ICAgUENJX0RNQV9GUk9NREVWSUNFKTsKLQkJaWYgKHByaXYtPnBjaV9tYXBfcnhfYWRkcmVzc1tp bmRleF0gPT0gKGRtYV9hZGRyX3QpIE5VTEwpIHsKKwkJaWYgKHVubGlrZWx5KHByaXYtPnBjaV9t YXBfcnhfYWRkcmVzc1tpbmRleF0gPT0gKGRtYV9hZGRyX3QpIE5VTEwpKSB7CiAJCQkvKiBlcnJv ciBtYXBwaW5nIHRoZSBidWZmZXIgdG8gZGV2aWNlIGFjY2Vzc2FibGUgbWVtb3J5IGFkZHJlc3Mg Ki8KIAkJCURFQlVHKFNIT1dfRVJST1JfTUVTU0FHRVMsCiAJCQkgICAgICAiRXJyb3IgbWFwcGlu ZyBETUEgYWRkcmVzc1xuIik7CmRpZmYgLU5hdXJFYkIgbGludXgtMi42LjZjdC9kcml2ZXJzL25l dC93aXJlbGVzcy9wcmlzbTU0L2lzbHBjaV9tZ3QuaCBsaW51eC0yLjYuNi0wMS9kcml2ZXJzL25l dC93aXJlbGVzcy9wcmlzbTU0L2lzbHBjaV9tZ3QuaAotLS0gbGludXgtMi42LjZjdC9kcml2ZXJz L25ldC93aXJlbGVzcy9wcmlzbTU0L2lzbHBjaV9tZ3QuaAkyMDA0LTA1LTI4IDE0OjQwOjI3LjAw MDQ1NDEzNiArMDIwMAorKysgbGludXgtMi42LjYtMDEvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJp c201NC9pc2xwY2lfbWd0LmgJMjAwNC0wNS0yOCAxNTozMzo0Mi4xODg3MTE2ODggKzAyMDAKQEAg LTM0LDcgKzM0LDcgQEAKICNkZWZpbmUgVFJBQ0UoZGV2bmFtZSkgICBLX0RFQlVHKFNIT1dfVFJB Q0lORywgVkVSQk9TRSwgIiVzOiAgLT4gIiBfX0ZVTkNUSU9OX18gIigpXG4iLCBkZXZuYW1lKQog CiBleHRlcm4gaW50IHBjX2RlYnVnOwotc3RhdGljIGNvbnN0IGludCBpbml0X3dkcyA9IDA7CS8q IGhlbHAgY29tcGlsZXIgb3B0aW1pemUgYXdheSBkZWFkIGNvZGUgKi8KKyNkZWZpbmUgaW5pdF93 ZHMgICAwCS8qIGhlbHAgY29tcGlsZXIgb3B0aW1pemUgYXdheSBkZWFkIGNvZGUgKi8KIAogCiAv KiBHZW5lcmFsIGRyaXZlciBkZWZpbml0aW9ucyAqLwpkaWZmIC1OYXVyRWJCIGxpbnV4LTIuNi42 Y3QvZHJpdmVycy9uZXQvd2lyZWxlc3MvcHJpc201NC9wcmlzbWNvbXBhdC5oIGxpbnV4LTIuNi42 LTAxL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3ByaXNtNTQvcHJpc21jb21wYXQuaAotLS0gbGludXgt Mi42LjZjdC9kcml2ZXJzL25ldC93aXJlbGVzcy9wcmlzbTU0L3ByaXNtY29tcGF0LmgJMjAwNC0w NS0yOCAxNDo0MDoyNy4wMDM0NTM2ODAgKzAyMDAKKysrIGxpbnV4LTIuNi42LTAxL2RyaXZlcnMv bmV0L3dpcmVsZXNzL3ByaXNtNTQvcHJpc21jb21wYXQuaAkyMDA0LTA1LTI4IDE1OjMzOjQyLjE5 MDcxMTM4NCArMDIwMApAQCAtMzIsNiArMzIsNyBAQAogI2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5o PgogI2luY2x1ZGUgPGxpbnV4L21vZHVsZXBhcmFtLmg+CiAjaW5jbHVkZSA8bGludXgvd29ya3F1 ZXVlLmg+CisjaW5jbHVkZSA8bGludXgvY29tcGlsZXIuaD4KIAogI2lmICFkZWZpbmVkKENPTkZJ R19GV19MT0FERVIpICYmICFkZWZpbmVkKENPTkZJR19GV19MT0FERVJfTU9EVUxFKQogI2Vycm9y IEZpcm13YXJlIExvYWRpbmcgaXMgbm90IGNvbmZpZ3VyZWQgaW4gdGhlIGtlcm5lbCAhCg== --=====================_50498543==_-- From russ@elegant-software.com Tue Jun 1 15:45:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 15:45:34 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51MjPgi001064 for ; Tue, 1 Jun 2004 15:45:26 -0700 Received: from michael.elegant-software.com (pcp04414833pcs.nrockv01.md.comcast.net[69.140.188.59]) by comcast.net (sccrmhc13) with ESMTP id <2004060122451901600q73fne>; Tue, 1 Jun 2004 22:45:19 +0000 Received: from elegant-software.com (unknown [192.168.2.4]) by michael.elegant-software.com (Postfix) with ESMTP id DE6CD47831; Tue, 1 Jun 2004 18:48:28 -0400 (EDT) Message-ID: <40BD07BC.8030302@elegant-software.com> Date: Tue, 01 Jun 2004 18:48:28 -0400 From: Russell Leighton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Stevens Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040609040703050508040004" X-archive-position: 5525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: russ@elegant-software.com Precedence: bulk X-list: netdev Content-Length: 10559 Lines: 279 This is a multi-part message in MIME format. --------------040609040703050508040004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for the suggestion. I tried using the interface itself and INADDR_ANY...the signals are not being received under 2.6 (FedoraCore2) UNLESS tcpdump is running...note this works fine under 2.4. Below is the code fragment that sets up the socket (the previous email had the code fragment that sets up the posix rt signals on the fd), any help would be greatly appreciated: /* mc_fd */ { /* make it */ if ( (h->state.mc_fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1 ) { aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot create socket: %s", strerror(errno)); goto error; } /* set it to nonblocking so that this can be async */ if ( fcntl(h->state.mc_fd, F_SETFL, O_NONBLOCK) == -1) { aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket nonblocking: %s", strerror(errno)); goto error; } /* set the mc interface */ if ( setsockopt(h->state.mc_fd, IPPROTO_IP, IP_MULTICAST_IF, &(h->mcast_if_addr), sizeof(h->mcast_if_addr)) < 0 ) { u_int8_t *ip = (u_int8_t *)&(h->mcast_if_addr); aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket IP_MULTICAST_IF for %u.%u.%u.%u: %s", ip[0],ip[1],ip[2],ip[4], strerror(errno)); goto error; } { /* debugging where packets are going when you have many interfaces is a pain, you want to log this! */ u_int8_t *ip = (u_int8_t *)&(h->mcast_if_addr); aw_log(h->handler_header.logger, AW_INFO_LOG_LEVEL, "mcrxhandler running multicast on interface %u.%u.%u.%u", ip[0],ip[1],ip[2],ip[3]); } /* use setsockopt() to request that the kernel join a multicast group */ { struct ip_mreq mreq; /* set up */ memset(&mreq, 0 , sizeof(mreq)); mreq.imr_multiaddr.s_addr= h->mcast_grp_addr.sin_addr.s_addr; mreq.imr_interface.s_addr= h->mcast_if_addr.s_addr; if (setsockopt(h->state.mc_fd, IPPROTO_IP,IP_ADD_MEMBERSHIP, (char *)&mreq, sizeof(mreq)) < 0) { aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket IPPROTO_IP,IP_ADD_MEMBERSHIP: %s", strerror(errno)); goto error; } } /* so we can have many processes listening to mcast */ { int32_t itmp = 1; if ( setsockopt(h->state.mc_fd, SOL_SOCKET, SO_REUSEADDR , (char *)&itmp, sizeof(itmp)) < 0 ) { aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket SO_REUSEADDR: %s", strerror(errno)); } } /* bind to receive messages */ if (bind(h->state.mc_fd, (struct sockaddr *)&(h->mcast_grp_addr), sizeof(h->mcast_grp_addr)) < 0) { aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot bind to multicast socket", strerror(errno)); goto error ; } /* add callback to handle packets on mc_fd */ aw_add_handler_fdcallback(mon, (aw_handler_t *)h, h->state.mc_fd, do_read); } /* end mc_fd */ David Stevens wrote: >>In the udp case, I when I listen for multicast packets my app only >>receives them when I am running a tcpdump (bizarre!). >> >> > >Russ, > This piece (which I expect has nothing to do with the other >problems you mentioned) sounds like you haven't joined the groups on >the interface on which you're receiving the multicast packets. >"tcpdump" will place the interface in "promiscuous mode" which will >receive all packets, and ordinary packet delivery will allow >the application to receive them, even if you haven't joined the group >on the relevant interface. > To verify if the group joins is broken, you can look at >/proc/net/igmp. If the groups you're joining are not listed on the >interface you want, the program isn't joining the groups correctly. >Group membership is per-interface, so joining a group on one interface >does not join it on another. > Feel free to contact me if you need some help debugging the >multicast problem. > > +-DLS > > > > > --------------040609040703050508040004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the suggestion.

I tried using the interface itself and INADDR_ANY...the signals are not being received under 2.6 (FedoraCore2) UNLESS tcpdump is running...note this works fine under 2.4.

Below is the code fragment that sets up the socket (the previous email had the code fragment that sets up the posix rt signals on the fd), any help would be greatly appreciated:

  /* mc_fd */
  {

    /* make it */
    if ( (h->state.mc_fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1 ) {
      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot create socket: %s", strerror(errno));
      goto error;
    }

    /* set it to nonblocking so that this can be async */
    if ( fcntl(h->state.mc_fd,  F_SETFL, O_NONBLOCK)  == -1) {
      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket nonblocking: %s", strerror(errno));
      goto error;
    }

    /* set the mc interface */
    if ( setsockopt(h->state.mc_fd, IPPROTO_IP, IP_MULTICAST_IF, &(h->mcast_if_addr), sizeof(h->mcast_if_addr)) < 0 ) {
      u_int8_t
    *ip = (u_int8_t *)&(h->mcast_if_addr);

      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL,
         "mcrxhandler cannot set socket IP_MULTICAST_IF for %u.%u.%u.%u: %s",
         ip[0],ip[1],ip[2],ip[4],
         strerror(errno));
      goto error;
    }

    { /* debugging where packets are going when you have many interfaces is a pain, you want to log this! */
      u_int8_t
    *ip = (u_int8_t *)&(h->mcast_if_addr);
      aw_log(h->handler_header.logger,  AW_INFO_LOG_LEVEL, "mcrxhandler running multicast on interface %u.%u.%u.%u",
         ip[0],ip[1],ip[2],ip[3]);
    }

    /* use setsockopt() to request that the kernel join a multicast group */
    {
      struct ip_mreq
    mreq;

      /* set up */
      memset(&mreq, 0 , sizeof(mreq));
      mreq.imr_multiaddr.s_addr= h->mcast_grp_addr.sin_addr.s_addr;
      mreq.imr_interface.s_addr= h->mcast_if_addr.s_addr;

      if (setsockopt(h->state.mc_fd, IPPROTO_IP,IP_ADD_MEMBERSHIP, (char *)&mreq, sizeof(mreq)) < 0) {
    aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL,
           "mcrxhandler cannot set socket IPPROTO_IP,IP_ADD_MEMBERSHIP: %s", strerror(errno));
    goto error;
      }
    }

    /* so we can have many processes listening to mcast */
    {
      int32_t
    itmp = 1;
      if ( setsockopt(h->state.mc_fd, SOL_SOCKET, SO_REUSEADDR , (char *)&itmp, sizeof(itmp)) < 0 ) {
    aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket SO_REUSEADDR: %s", strerror(errno));
      }
    }

    /* bind to receive messages */
    if (bind(h->state.mc_fd, (struct sockaddr *)&(h->mcast_grp_addr), sizeof(h->mcast_grp_addr)) < 0) {
      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot bind to multicast socket", strerror(errno));
      goto error ;
    }

    /* add callback to handle packets on mc_fd */
    aw_add_handler_fdcallback(mon, (aw_handler_t *)h, h->state.mc_fd, do_read);

  } /* end mc_fd */




David Stevens wrote: 
In the udp case, I when I listen for multicast packets my app only
receives them when I am running a tcpdump (bizarre!).
    

Russ,
        This piece (which I expect has nothing to do with the other
problems you mentioned) sounds like you haven't joined the groups on
the interface on which you're receiving the multicast packets.
"tcpdump" will place the interface in "promiscuous mode" which will
receive all packets, and ordinary packet delivery will allow
the application to receive them, even if you haven't joined the group
on the relevant interface.
        To verify if the group joins is broken, you can look at
/proc/net/igmp. If the groups you're joining are not listed on the
interface you want, the program isn't joining the groups correctly.
Group membership is per-interface, so joining a group on one interface
does not join it on another.
        Feel free to contact me if you need some help debugging the
multicast problem.

                                                        +-DLS

--------------040609040703050508040004-- From russ@elegant-software.com Tue Jun 1 16:05:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 16:05:51 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51N5ngi002060 for ; Tue, 1 Jun 2004 16:05:49 -0700 Received: from michael.elegant-software.com (pcp04414833pcs.nrockv01.md.comcast.net[69.140.188.59]) by comcast.net (sccrmhc13) with ESMTP id <2004060123054301600q6aq5e>; Tue, 1 Jun 2004 23:05:43 +0000 Received: from elegant-software.com (unknown [192.168.2.4]) by michael.elegant-software.com (Postfix) with ESMTP id 7DC8947831; Tue, 1 Jun 2004 19:08:48 -0400 (EDT) Message-ID: <40BD0C80.7080607@elegant-software.com> Date: Tue, 01 Jun 2004 19:08:48 -0400 From: Russell Leighton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Stevens Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets? References: <40BD07BC.8030302@elegant-software.com> In-Reply-To: <40BD07BC.8030302@elegant-software.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: russ@elegant-software.com Precedence: bulk X-list: netdev Content-Length: 4769 Lines: 144 I forgot to answer your question, I confirmed via the proc interface that the group has been joined. I am thinking the issue is related to F_SETSIG. I don't read() until I get a signal and I am not getting ANY signals for the multicast data. Googling around a little I saw changes in the futex code around FUTEX_FD ... perhaps there is a bug? Cobbling together a small test piece of code is the next thing to do... Russell Leighton wrote: > Thanks for the suggestion. > > I tried using the interface itself and INADDR_ANY...the signals are > not being received under 2.6 (FedoraCore2) UNLESS tcpdump is > running...note this works fine under 2.4. > > Below is the code fragment that sets up the socket (the previous email > had the code fragment that sets up the posix rt signals on the fd), > any help would be greatly appreciated: > > /* mc_fd */ > { > > /* make it */ > if ( (h->state.mc_fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1 ) { > aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, > "mcrxhandler cannot create socket: %s", strerror(errno)); > goto error; > } > > /* set it to nonblocking so that this can be async */ > if ( fcntl(h->state.mc_fd, F_SETFL, O_NONBLOCK) == -1) { > aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, > "mcrxhandler cannot set socket nonblocking: %s", strerror(errno)); > goto error; > } > > /* set the mc interface */ > if ( setsockopt(h->state.mc_fd, IPPROTO_IP, IP_MULTICAST_IF, > &(h->mcast_if_addr), sizeof(h->mcast_if_addr)) < 0 ) { > u_int8_t > *ip = (u_int8_t *)&(h->mcast_if_addr); > > aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, > "mcrxhandler cannot set socket IP_MULTICAST_IF for > %u.%u.%u.%u: %s", > ip[0],ip[1],ip[2],ip[4], > strerror(errno)); > goto error; > } > > { /* debugging where packets are going when you have many > interfaces is a pain, you want to log this! */ > u_int8_t > *ip = (u_int8_t *)&(h->mcast_if_addr); > aw_log(h->handler_header.logger, AW_INFO_LOG_LEVEL, > "mcrxhandler running multicast on interface %u.%u.%u.%u", > ip[0],ip[1],ip[2],ip[3]); > } > > /* use setsockopt() to request that the kernel join a multicast > group */ > { > struct ip_mreq > mreq; > > /* set up */ > memset(&mreq, 0 , sizeof(mreq)); > mreq.imr_multiaddr.s_addr= h->mcast_grp_addr.sin_addr.s_addr; > mreq.imr_interface.s_addr= h->mcast_if_addr.s_addr; > > if (setsockopt(h->state.mc_fd, IPPROTO_IP,IP_ADD_MEMBERSHIP, > (char *)&mreq, sizeof(mreq)) < 0) { > aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, > "mcrxhandler cannot set socket > IPPROTO_IP,IP_ADD_MEMBERSHIP: %s", strerror(errno)); > goto error; > } > } > > /* so we can have many processes listening to mcast */ > { > int32_t > itmp = 1; > if ( setsockopt(h->state.mc_fd, SOL_SOCKET, SO_REUSEADDR , (char > *)&itmp, sizeof(itmp)) < 0 ) { > aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler > cannot set socket SO_REUSEADDR: %s", strerror(errno)); > } > } > > /* bind to receive messages */ > if (bind(h->state.mc_fd, (struct sockaddr *)&(h->mcast_grp_addr), > sizeof(h->mcast_grp_addr)) < 0) { > aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, > "mcrxhandler cannot bind to multicast socket", strerror(errno)); > goto error ; > } > > /* add callback to handle packets on mc_fd */ > aw_add_handler_fdcallback(mon, (aw_handler_t *)h, h->state.mc_fd, > do_read); > > } /* end mc_fd */ > > > > > David Stevens wrote: > >>>In the udp case, I when I listen for multicast packets my app only >>>receives them when I am running a tcpdump (bizarre!). >>> >>> >> >>Russ, >> This piece (which I expect has nothing to do with the other >>problems you mentioned) sounds like you haven't joined the groups on >>the interface on which you're receiving the multicast packets. >>"tcpdump" will place the interface in "promiscuous mode" which will >>receive all packets, and ordinary packet delivery will allow >>the application to receive them, even if you haven't joined the group >>on the relevant interface. >> To verify if the group joins is broken, you can look at >>/proc/net/igmp. If the groups you're joining are not listed on the >>interface you want, the program isn't joining the groups correctly. >>Group membership is per-interface, so joining a group on one interface >>does not join it on another. >> Feel free to contact me if you need some help debugging the >>multicast problem. >> >> +-DLS >> >> >> >> >> > From herbert@gondor.apana.org.au Tue Jun 1 16:29:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 16:29:09 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i51NT1gi006029 for ; Tue, 1 Jun 2004 16:29: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 1BVIgD-0005oY-00; Wed, 02 Jun 2004 09:28:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BVIg3-0006jc-00; Wed, 02 Jun 2004 09:28:15 +1000 Date: Wed, 2 Jun 2004 09:28:15 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: [PLIP] Check cmd in plip_ioctl Message-ID: <20040601232814.GA25876@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5527 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: 1069 Lines: 39 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff: I received a bug report that a PLIP interface was incorrectly identified as wireless because plip_ioctl did not check what the value of cmd is before processing the request. This patch fixes exactly 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 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/plip.c 1.20 vs edited ===== --- 1.20/drivers/net/plip.c 2004-03-04 05:52:24 +11:00 +++ edited/drivers/net/plip.c 2004-06-02 09:21:05 +10:00 @@ -1219,6 +1219,9 @@ struct net_local *nl = netdev_priv(dev); struct plipconf *pc = (struct plipconf *) &rq->ifr_data; + if (cmd != SIOCDEVPLIP) + return -EOPNOTSUPP; + switch(pc->pcmd) { case PLIP_GET_TIMEOUT: pc->trigger = nl->trigger; --oyUTqETQ0mS9luUI-- From tharbaugh@lnxi.com Tue Jun 1 21:02:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 21:02:17 -0700 (PDT) Received: from ash.lnxi.com (208.177.141.226.ptr.us.xo.net [208.177.141.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5242Dgi016568 for ; Tue, 1 Jun 2004 21:02:13 -0700 Received: (qmail 16728 invoked from network); 1 Jun 2004 23:18:46 -0000 Received: from tubarao.lnxi.com (HELO ?192.168.15.106?) (192.168.15.106) by ash.lnxi.com with SMTP; 1 Jun 2004 23:18:46 -0000 Subject: [PATCH] abysmal e1000 performance (DITR) From: Thayne Harbaugh Reply-To: tharbaugh@lnxi.com To: netdev@oss.sgi.com Cc: ganesh.venkatesan@intel.com Content-Type: text/plain Organization: Linux Networx Message-Id: <1086131111.20113.22.camel@tubarao> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 01 Jun 2004 17:05:12 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 5529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tharbaugh@lnxi.com Precedence: bulk X-list: netdev Content-Length: 4106 Lines: 99 The introduction of Dynamic Interrupt Throttling Rate (DITR) in the 4.x -> 5.x e1000 driver change can cause serious performance problems. The ITR can be reduced when the system is *not* under load which results in gratuitous latencies for network traffic. In other words - why is the interrupt load reduced when the system isn't under load? This is a patch to include system load when calculating the DITR. It only allows the diff/goc ratio to factor into the DITR when the 1 minute load average is above .50. It appears to work quite well and prevents throttling when the load is below .50 and allows throttling when the load is in excess of .50. There are a few concerns. The patch requires kernel/timer.c to EXPORT_SYMBOL(avenrun) - otherwise the symbol isn't available to the driver when built as a module. This symbol "clutter" may be undesirable to some. Another concern is that NAPI accomplishes a similar interrupt load reduction and is likely a better solution than ITR. diff -ur linux-2.4.21-99/drivers/net/e1000/e1000_main.c linux-2.4.21-99-e1000/drivers/net/e1000/e1000_main.c --- linux-2.4.21-99/drivers/net/e1000/e1000_main.c 2003-09-24 05:47:33.000000000 -0700 +++ linux-2.4.21-99-e1000/drivers/net/e1000/e1000_main.c 2004-05-27 23:38:02.000000000 -0700 @@ -27,6 +27,8 @@ *******************************************************************************/ #include "e1000.h" +/* for avenrun[] */ +#include /* Change Log * @@ -1429,14 +1431,34 @@ /* Dynamic mode for Interrupt Throttle Rate (ITR) */ if(adapter->hw.mac_type >= e1000_82540 && adapter->itr == 1) { + /* fixed fractional part of .50 */ +#define FIXED_F50 (FIXED_1 >> 1) + /* This maps the range of .50-.99 -> 0-100 */ +#define FIXED_1_MAPPED (FIXED_1 - FIXED_F50) + unsigned long laf; /* load average fractional part */ + uint32_t goc; /* good octet count */ + uint32_t dif; /* dif between tx and rx goc */ + uint32_t itr; /* inturrept throttle rate */ + /* laf range is mapped: + * .00-.50 -> .00 + * .50-.99 -> .00-.99 + * 1.00+ -> 1.00 */ + if (avenrun[0] + FIXED_1/200 > FIXED_1) + laf = FIXED_1_MAPPED; + else if (avenrun[0] + FIXED_1/200 < FIXED_F50) + laf = 0; + else + laf = ((avenrun[0] + FIXED_1/2000) & (FIXED_1 - 1)) - FIXED_1_MAPPED; /* Symmetric Tx/Rx gets a reduced ITR=2000; Total * asymmetrical Tx or Rx gets ITR=8000; everyone * else is between 2000-8000. */ - uint32_t goc = (adapter->gotcl + adapter->gorcl) / 10000; - uint32_t dif = (adapter->gotcl > adapter->gorcl ? - adapter->gotcl - adapter->gorcl : - adapter->gorcl - adapter->gotcl) / 10000; - uint32_t itr = goc > 0 ? (dif * 6000 / goc + 2000) : 8000; + goc = (adapter->gotcl + adapter->gorcl) / 10000; + dif = (adapter->gotcl > adapter->gorcl ? + adapter->gotcl - adapter->gorcl : + adapter->gorcl - adapter->gotcl) / 10000; + itr = goc > 0 + ? 8000 + 6000*laf/FIXED_1_MAPPED*dif/goc - 6000*laf/FIXED_1_MAPPED + : 8000; E1000_WRITE_REG(&adapter->hw, ITR, 1000000000 / (itr * 256)); } diff -ur linux-2.4.21-99/kernel/Makefile linux-2.4.21-99-e1000/kernel/Makefile --- linux-2.4.21-99/kernel/Makefile 2003-09-24 05:47:27.000000000 -0700 +++ linux-2.4.21-99-e1000/kernel/Makefile 2004-05-26 23:45:47.000000000 -0700 @@ -11,7 +11,7 @@ export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o exec_domain.o \ printk.o cpufreq.o rcupdate.o syscall_ksyms.o fork.o hook.o \ - rashooks.o module.o + rashooks.o module.o timer.o obj-y = sched.o dma.o fork.o exec_domain.o panic.o printk.o \ module.o exit.o itimer.o info.o time.o softirq.o resource.o \ diff -ur linux-2.4.21-99/kernel/timer.c linux-2.4.21-99-e1000/kernel/timer.c --- linux-2.4.21-99/kernel/timer.c 2003-09-24 05:47:27.000000000 -0700 +++ linux-2.4.21-99-e1000/kernel/timer.c 2004-05-27 00:54:29.000000000 -0700 @@ -686,6 +686,7 @@ * all seem to differ on different machines. */ unsigned long avenrun[3]; +EXPORT_SYMBOL(avenrun); static inline void calc_load(unsigned long ticks) { -- Thayne Harbaugh Linux Networx From amit_kulkarni@fastermail.com Tue Jun 1 22:23:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jun 2004 22:23:57 -0700 (PDT) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i525Nugi020087 for ; Tue, 1 Jun 2004 22:23:56 -0700 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 7285D1800DF2 for ; Wed, 2 Jun 2004 05:23:51 +0000 (GMT) X-OB-Received: from unknown (205.158.62.133) by wfilter.us4.outblaze.com; 2 Jun 2004 05:23:24 -0000 Received: by ws5-3.us4.outblaze.com (Postfix, from userid 1001) id F110123BFE; Wed, 2 Jun 2004 05:23:54 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [203.190.146.100] by ws5-3.us4.outblaze.com with http for amit_kulkarni@fastermail.com; Wed, 02 Jun 2004 13:23:54 +0800 From: "am ku" To: netdev@oss.sgi.com Date: Wed, 02 Jun 2004 13:23:54 +0800 Subject: need some help aboot queueing disciplines X-Originating-Ip: 203.190.146.100 X-Originating-Server: ws5-3.us4.outblaze.com Message-Id: <20040602052354.F110123BFE@ws5-3.us4.outblaze.com> X-archive-position: 5533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amit_kulkarni@fastermail.com Precedence: bulk X-list: netdev Content-Length: 575 Lines: 11 heelo all, i am trying to get some knowledge on the queueing disciplines, i have gone through "Linux advanced routing and traffic control HOWTO". i need to know which discipline is the best for clients. i.e can i impart the parameter of say, htb on systems which are in client server architecture and ar eworking as clients. or it is best suited for servers only. can anyone who has already worked on this guide me. please reply as soon as possible. amit -- _______________________________________________ Get your free email from http://fastermail.com Powered by Outblaze From mcgrof@studorgs.rutgers.edu Wed Jun 2 00:14:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 00:15:14 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i527Eogi023870 for ; Wed, 2 Jun 2004 00:14:51 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id EB056F9D4B; Wed, 2 Jun 2004 03:14:49 -0400 (EDT) Date: Wed, 2 Jun 2004 03:14:49 -0400 To: Netdev Cc: hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel Subject: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040602071449.GJ10723@ruslug.rutgers.edu> Mail-Followup-To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" 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: 5536 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: 1679 Lines: 49 --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So WPA is now a priority for prism54 development. Here's where we're at.=20 Long ago in January Jouni had added some wpa supplicant support into=20 prism54. It's not until today when I started looking into wpa_supplicant. I'm glad wpa_supplicant exists :). Interacting with it *is* our missing link to getting full WPA support (great job Jouni). In wpa_supplicant=20 cvs I see a base code for driver_prism54.c (empty routines, just providing = skeleton). Well I'll be diving in it now and see where I can get. If anyone else is interested in helping with WPA support for prism54, working with wpa_supplicant is the way to go. I'm curious though -- wpa_supplicant is pretty much userspace. This was done with good intentions from what I read but before we get dirty=20 with wpa_supplicant I'm wondering if we should just integrate a lot of=20 wpa_supplicant into kernel space (specifically wireless tools). Regardless, as Jouni points out, there is still a framework for WPA that ne= eds to be written for all linux wireless drivers, whether it's to assist wpa_supplicant framework or to integrate wpa_supplicant into kernel space. What's the plan? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAvX5pat1JN+IKUl4RAryQAJ4tsfPhMRmq85oWK85LGz5PE0XK1ACfSpIO S4LRkAtZVTbKdKpKb3oZ0e4= =XKLg -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C-- From pj@sgi.com Wed Jun 2 02:21:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 02:21:56 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i529Lngi032112 for ; Wed, 2 Jun 2004 02:21:49 -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 i529RwFe019662 for ; Wed, 2 Jun 2004 02:27:58 -0700 Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.103]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id i529LSl614158725; Wed, 2 Jun 2004 02:21:28 -0700 (PDT) Date: Wed, 2 Jun 2004 02:21:30 -0700 From: Paul Jackson To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: 2.6.7-rc2-mm1 - bk-netdev.patch e1000_ethtool.c doesn't build Message-Id: <20040602022130.35a7571d.pj@sgi.com> In-Reply-To: <20040601021539.413a7ad7.akpm@osdl.org> References: <20040601021539.413a7ad7.akpm@osdl.org> Organization: SGI X-Mailer: Sylpheed version 0.9.8 (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: 5537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev Content-Length: 1203 Lines: 28 The patch bk-netdev.patch in 2.6.7-rc2-mm1 doesn't compile. It contains the following change, which creates two identical e1000_gstrings_stats[] opening declaration lines in a row, and many many gcc errors, starting with: > drivers/net/e1000/e1000_ethtool.c:57: error: parse error before "static" diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c 2004-05-31 16:18:26 -07:00 +++ b/drivers/net/e1000/e1000_ethtool.c 2004-05-31 16:18:26 -07:00 @@ -54,6 +54,7 @@ #define E1000_STAT(m) sizeof(((struct e1000_adapter *)0)->m), \ offsetof(struct e1000_adapter, m) static const struct e1000_stats e1000_gstrings_stats[] = { +static const struct e1000_stats e1000_gstrings_stats[] = { { "rx_packets", E1000_STAT(net_stats.rx_packets) }, { "tx_packets", E1000_STAT(net_stats.tx_packets) }, { "rx_bytes", E1000_STAT(net_stats.rx_bytes) }, There may or may not be other errors past this - I have not gone there yet. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From pj@sgi.com Wed Jun 2 02:43:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 02:43:31 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i529hTgi002413 for ; Wed, 2 Jun 2004 02:43:29 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i529g2hv014449 for ; Wed, 2 Jun 2004 02:42:02 -0700 Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.103]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id i529fGl614151562; Wed, 2 Jun 2004 02:41:16 -0700 (PDT) Date: Wed, 2 Jun 2004 02:41:18 -0700 From: Paul Jackson To: Paul Jackson Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: 2.6.7-rc2-mm1 - bk-netdev.patch e1000_ethtool.c doesn't build Message-Id: <20040602024118.40dc9359.pj@sgi.com> In-Reply-To: <20040602022130.35a7571d.pj@sgi.com> References: <20040601021539.413a7ad7.akpm@osdl.org> <20040602022130.35a7571d.pj@sgi.com> Organization: SGI X-Mailer: Sylpheed version 0.9.8 (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: 5539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev Content-Length: 766 Lines: 22 > There may or may not be other errors past this ... There are other errors - many more such duplicated and near-duplicated lines, such as for one example the following. Someone's shotgun misfired and hit someone's foot. @@ -1440,8 +1554,10 @@ static void e1000_get_wol(struct net_device *netdev, struct ethtool_wolinfo *wol) +e1000_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; switch(adapter->hw.device_id) { -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From mitch@sfgoth.com Wed Jun 2 03:27:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 03:27:45 -0700 (PDT) Received: from gaz.sfgoth.com (gaz.sfgoth.com [69.36.241.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52ARfgi004160 for ; Wed, 2 Jun 2004 03:27:41 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.10/8.12.9) with ESMTP id i52AURIp075888; Wed, 2 Jun 2004 03:30:27 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.10/8.12.6/Submit) id i52AURLi075887; Wed, 2 Jun 2004 03:30:27 -0700 (PDT) (envelope-from mitch) Date: Wed, 2 Jun 2004 03:30:27 -0700 From: Mitchell Blank Jr To: "Ihar 'Philips' Filipau" Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: e1000 question Message-ID: <20040602103027.GA74881@gaz.sfgoth.com> References: <40BD8E49.3070605@giga-stream.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BD8E49.3070605@giga-stream.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 5540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Content-Length: 815 Lines: 18 Ihar 'Philips' Filipau wrote: > Functions e1000_clean_{t,r}x_irq are very similar: both of them are > checking descriptor flag updated by nic. > Host CPU, obviously, to perform this check, will cache descriptor. > If, say e1000_clean_rx_irq() will be called twice in short time > range, I expect that it can miss change of the flag, since old flag may > still sit in host CPU cache. Please see Documentation/DMA-mapping.txt; especially the part starting at "There are two types of DMA mappings..." Ring buffers are allocated as "consistent" DMA memory. For most architectures this will mean that the cache hardware snoops the PCI bus and automatically invalidates cache lines as they are written to. For architectures that can't do that then Linux will mark those memory regions uncacheable. -Mitch From P@draigBrady.com Wed Jun 2 03:35:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 03:35:45 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52AZggi004897 for ; Wed, 2 Jun 2004 03:35:43 -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 i52AZfaq010038 for ; Wed, 2 Jun 2004 11:35:41 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40BDAD7D.2010307@draigBrady.com> Date: Wed, 02 Jun 2004 11:35:41 +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: netdev@oss.sgi.com Subject: BCM570[13] packet classification? Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i52AZfaq010038 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i52AZggi004897 X-archive-position: 5542 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: 261 Lines: 13 Hi, I just noticed that on broadcom's site they mention that the BCM570[13] controllers can do packet classification: http://www.broadcom.com/collateral/pb/5703-PB01-RDS.pdf However I can't find any thirdparty references to it. Any ideas? thanks, Pádraig. From ifilipau@giga-stream.de Wed Jun 2 04:24:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 04:24:17 -0700 (PDT) Received: from natsmtp00.rzone.de (natsmtp00.rzone.de [81.169.145.165]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52BO8gi010083 for ; Wed, 2 Jun 2004 04:24:09 -0700 Received: from giga-stream.de ([212.18.200.6]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i52AZ2qK025382; Wed, 2 Jun 2004 12:35:02 +0200 (MEST) Message-ID: <40BDAD3C.3030103@giga-stream.de> Date: Wed, 02 Jun 2004 12:34:36 +0200 From: "Ihar 'Philips' Filipau" Organization: Giga Stream User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mitchell Blank Jr CC: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: e1000 question References: <40BD8E49.3070605@giga-stream.de> <20040602103027.GA74881@gaz.sfgoth.com> In-Reply-To: <20040602103027.GA74881@gaz.sfgoth.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050103070102000008040302" X-archive-position: 5544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ifilipau@giga-stream.de Precedence: bulk X-list: netdev Content-Length: 6703 Lines: 117 This is a cryptographically signed message in MIME format. --------------ms050103070102000008040302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks, Mitch! That explains everything. Went reading pci_alloc_consistent()'s RTFM. That is exactly what I was missing in couple of my drivers. Mitchell Blank Jr wrote: > Ihar 'Philips' Filipau wrote: > >> Functions e1000_clean_{t,r}x_irq are very similar: both of them are >>checking descriptor flag updated by nic. >> Host CPU, obviously, to perform this check, will cache descriptor. >> If, say e1000_clean_rx_irq() will be called twice in short time >>range, I expect that it can miss change of the flag, since old flag may >>still sit in host CPU cache. > > > Please see Documentation/DMA-mapping.txt; especially the part starting > at "There are two types of DMA mappings..." Ring buffers are allocated > as "consistent" DMA memory. > > For most architectures this will mean that the cache hardware snoops the > PCI bus and automatically invalidates cache lines as they are written to. > For architectures that can't do that then Linux will mark those memory > regions uncacheable. > -- Johnson's law: Systems resemble the organizations that create them. -- ___ ___ Ihar 'Philips' Filipau \ / Sr. Software Developer Tel: +49 681 959 16 0 \ / GIGA STREAM Fax: +49 681 959 16 100 \/ Konrad Zuse Strasse 7 Mobile: +49 173 39 462 49 /\ 66115 Saarbruecken email: ifilipau@giga-stream.de / \ Germany www: http://www.giga-stream.de ___/ \___ Switching for success --------------ms050103070102000008040302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXDCC AwwwggJ1oAMCAQICAwp5RzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwNDEyMDI1OVoXDTA0MDgwMzEyMDI1OVowSTEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEmMCQGCSqGSIb3DQEJARYXaWZpbGlw YXVAZ2lnYS1zdHJlYW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCh23lX NmvjlqAwzhanhztIary04F8dGaAt4ABMEMiNf+XD353lzpIHcHVzTH0OY4c9LtFNbt5V+XZT JoENrCLlDDCerzYgVNEejB173dpMQW1mAoYgl5AJZArvjgojcSKWG+BMaD2ozo3NVAPMAkwD Zhk25/WtbqN4UDf2mGljaU4/SETZKUJ+pNeeiXoz2KHlkJyZ8zubjJuR7xf5hPMpfsV+ePHI ohDZAFlM58D6wpgbDp8DO5CL4dnqSLeW+xCv+ETDIATu8B80Cv4QifhTWIJsosEzFP6CljUE hdBDbr3sgPTdVbTewTptD4hKodp67/2WjWsS6DMZwZl7oyTTAgMBAAGjNDAyMCIGA1UdEQQb MBmBF2lmaWxpcGF1QGdpZ2Etc3RyZWFtLmRlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE BQADgYEAXUjvmMsvEKRjvE8E2xjjymWYARwQ9fj/jbf/bpEy+fxub4It78X93RyBEazIciky +H3ZVmjTUH+dnxzYpBrEztVIuKDsCkuF5++j+NXDsELsuOFNX+1Z/YZ4ol5rJaensb/ZwflA byaeNV7+nl7qUgPxTanF16QDv13+EumlMdUwggMMMIICdaADAgECAgMKeUcwDQYJKoZIhvcN AQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA4 MDQxMjAyNTlaFw0wNDA4MDMxMjAyNTlaMEkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxJjAkBgkqhkiG9w0BCQEWF2lmaWxpcGF1QGdpZ2Etc3RyZWFtLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAodt5VzZr45agMM4Wp4c7SGq8tOBfHRmgLeAATBDI jX/lw9+d5c6SB3B1c0x9DmOHPS7RTW7eVfl2UyaBDawi5Qwwnq82IFTRHowde93aTEFtZgKG IJeQCWQK744KI3EilhvgTGg9qM6NzVQDzAJMA2YZNuf1rW6jeFA39phpY2lOP0hE2SlCfqTX nol6M9ih5ZCcmfM7m4ybke8X+YTzKX7FfnjxyKIQ2QBZTOfA+sKYGw6fAzuQi+HZ6ki3lvsQ r/hEwyAE7vAfNAr+EIn4U1iCbKLBMxT+gpY1BIXQQ2697ID03VW03sE6bQ+ISqHaeu/9lo1r EugzGcGZe6Mk0wIDAQABozQwMjAiBgNVHREEGzAZgRdpZmlsaXBhdUBnaWdhLXN0cmVhbS5k ZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF1I75jLLxCkY7xPBNsY48plmAEc EPX4/423/26RMvn8bm+CLe/F/d0cgRGsyHIpMvh92VZo01B/nZ8c2KQaxM7VSLig7ApLhefv o/jVw7BC7LjhTV/tWf2GeKJeayWnp7G/2cH5QG8mnjVe/p5e6lID8U2pxdekA79d/hLppTHV MIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAw MDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXa iBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1 Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3 MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGx S0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcN rUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTq JmmHf0iezqWf54TYyWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJl ZW1haWwgUlNBIDIwMDAuOC4zMAIDCnlHMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDYwMjEwMzQzNlowIwYJKoZIhvcNAQkE MRYEFJv4LpGyY/ToFFenFqRYT+Yaw6+1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnlHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3 dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBG cmVlbWFpbCBSU0EgMjAwMC44LjMwAgMKeUcwDQYJKoZIhvcNAQEBBQAEggEAWdFo0RZHu1If VOAFDP3OJ5SuKfa+zLUTiVtm03QSwobW2etA+mOir55ykHc+DAkQuz5rKEnioHctkq2H/pPl 8Aet4ZaXcYdlrIItQwdsmlsH2yyhruZMZjspjI4JZLSFDZD8NvruGLOciCuhFhqwg/3EmHUJ hHZN7K6YllILywp+lod2p1mFrcHFe8COsIv5lqp2ZnBv86LHEqYEYik6aWBnkWzepbr5CfDP 2bMcGTjz6QnEPY0lRgIH12Q8B7irPePD7gwaWu/EqYxdU8z4uLOaadFy5pOSRbArk3Kwarjw 9fz2GBds58stav+7nzZ4klo75SM2/wB/QJyjsv2oRgAAAAAAAA== --------------ms050103070102000008040302-- From rl@hellgate.ch Wed Jun 2 04:59:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 04:59:29 -0700 (PDT) Received: from mail5.bluewin.ch (mail5.bluewin.ch [195.186.1.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52BxKgi011032 for ; Wed, 2 Jun 2004 04:59:21 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail5.bluewin.ch (Bluewin AG 7.0.028) id 40A46B2100256F5E; Wed, 2 Jun 2004 11:59:01 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 4DED58CA75E; Wed, 2 Jun 2004 13:59:00 +0200 (CEST) Date: Wed, 2 Jun 2004 13:59:00 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [7/9][PATCH 2.6] Rewrite special-casing Message-ID: <20040602115900.GA17578@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 9492 Lines: 333 Use PCI revision to determine special cases. One bit field replaces a bunch of data structures holding special case information. Replace chip_id, drv_flags in rhine_private with quirks Remove enum rhine_chips, struct rhine_chip_info (and array), enum chip_capability_flags Add enum rhine_revs, enum rhine_quirks (some values in preparation for subsequent changes) wait_for_reset() and enable_mmio() now use quirks instead of chip_id Remove model names from ident strings for now. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -354,48 +354,46 @@ second only the 1234 card. */ -enum rhine_chips { - VT86C100A = 0, - VT6102, - VT6105, - VT6105M +enum rhine_revs { + VT86C100A = 0x00, + VT6102 = 0x40, + VT8231 = 0x50, /* Integrated MAC */ + VT8233 = 0x60, /* Integrated MAC */ + VT8235 = 0x74, /* Integrated MAC */ + VT8237 = 0x78, /* Integrated MAC */ + VTunknown0 = 0x7C, + VT6105 = 0x80, + VT6105_B0 = 0x83, + VT6105L = 0x8A, + VT6107 = 0x8C, + VTunknown1 = 0x8E, + VT6105M = 0x90, }; -struct rhine_chip_info { - const char *name; - int io_size; - int drv_flags; -}; - - -enum chip_capability_flags { - HasDavicomPhy=4, - ReqTxAlign=0x10, HasWOL=0x20, +enum rhine_quirks { + rqWOL = 0x0001, /* Wake-On-LAN support */ + rqForceReset = 0x0002, + rqDavicomPhy = 0x0020, + rq6patterns = 0x0040, /* 6 instead of 4 patterns for WOL */ + rqStatusWBRace = 0x0080, /* Tx Status Writeback Error possible */ + rqRhineI = 0x0100, /* See comment below */ }; +/* + * rqRhineI: VT86C100A (aka Rhine-I) uses different bits to enable + * MMIO as well as for the collision counter and the Tx FIFO underflow + * indicator. In addition, Tx and Rx buffers need to 4 byte aligned. + */ /* Beware of PCI posted writes */ #define IOSYNC do { readb(dev->base_addr + StationAddr); } while (0) -/* directly indexed by enum rhine_chips, above */ -static struct rhine_chip_info rhine_chip_info[] __devinitdata = -{ - { "VIA VT86C100A Rhine", 128, - ReqTxAlign | HasDavicomPhy }, - { "VIA VT6102 Rhine-II", 256, - HasWOL }, - { "VIA VT6105 Rhine-III", 256, - HasWOL }, - { "VIA VT6105M Rhine-III", 256, - HasWOL }, -}; - static struct pci_device_id rhine_pci_tbl[] = { - {0x1106, 0x3043, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VT86C100A}, - {0x1106, 0x3065, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VT6102}, - {0x1106, 0x3106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VT6105}, /* 6105{,L,LOM} */ - {0x1106, 0x3053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VT6105M}, - {0,} /* terminate list */ + {0x1106, 0x3043, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* VT86C100A */ + {0x1106, 0x3065, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* VT6102 */ + {0x1106, 0x3106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* 6105{,L,LOM} */ + {0x1106, 0x3053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* VT6105M */ + { } /* terminate list */ }; MODULE_DEVICE_TABLE(pci, rhine_pci_tbl); @@ -503,7 +501,7 @@ spinlock_t lock; /* Frequently used values: keep some adjacent for cache effect. */ - int chip_id, drv_flags; + u32 quirks; struct rx_desc *rx_head_desc; unsigned int cur_rx, dirty_rx; /* Producer/consumer ring indices */ unsigned int cur_tx, dirty_tx; @@ -545,12 +543,12 @@ intr_status = readw(ioaddr + IntrStatus); /* On Rhine-II, Bit 3 indicates Tx descriptor write-back race. */ - if (rp->chip_id == VT6102) + if (rp->quirks & rqStatusWBRace) intr_status |= readb(ioaddr + IntrStatus2) << 16; return intr_status; } -static void wait_for_reset(struct net_device *dev, int chip_id, char *name) +static void wait_for_reset(struct net_device *dev, u32 quirks, char *name) { long ioaddr = dev->base_addr; int boguscnt = 20; @@ -562,7 +560,7 @@ "Trying harder.\n", name); /* Rhine-II needs to be forced sometimes */ - if (chip_id == VT6102) + if (quirks & rqForceReset) writeb(0x40, ioaddr + MiscCmd); /* VT86C100A may need long delay after reset (dlink) */ @@ -578,10 +576,10 @@ } #ifdef USE_MMIO -static void __devinit enable_mmio(long ioaddr, int chip_id) +static void __devinit enable_mmio(long ioaddr, u32 quirks) { int n; - if (chip_id == VT86C100A) { + if (quirks & rqRhineI) { /* More recent docs say that this bit is reserved ... */ n = inb(ioaddr + ConfigA) | 0x20; outb(n, ioaddr + ConfigA); @@ -617,7 +615,8 @@ struct net_device *dev; struct rhine_private *rp; int i, option, rc; - int chip_id = (int) ent->driver_data; + u8 pci_rev; + u32 quirks; static int card_idx = -1; long ioaddr; long memaddr; @@ -626,6 +625,7 @@ #ifdef USE_MMIO long ioaddr0; #endif + const char *name; /* when built into the kernel, we only print version if device is found */ #ifndef MODULE @@ -636,7 +636,26 @@ card_idx++; option = card_idx < MAX_UNITS ? options[card_idx] : 0; - io_size = rhine_chip_info[chip_id].io_size; + pci_read_config_byte(pdev, PCI_REVISION_ID, &pci_rev); + + io_size = 256; + if (pci_rev < VT6102) { + quirks = rqRhineI | rqDavicomPhy; + io_size = 128; + name = "VT86C100A Rhine"; + } + else { + quirks = rqWOL | rqForceReset; + if (pci_rev < VT6105) { + name = "Rhine II"; + quirks |= rqStatusWBRace; /* Rhine-II exclusive */ + } + else { + name = "Rhine III"; + if (pci_rev >= VT6105_B0) + quirks |= rq6patterns; + } + } rc = pci_enable_device(pdev); if (rc) @@ -679,7 +698,7 @@ #ifdef USE_MMIO ioaddr0 = ioaddr; - enable_mmio(ioaddr0, chip_id); + enable_mmio(ioaddr0, quirks); ioaddr = (long) ioremap(memaddr, io_size); if (!ioaddr) { @@ -705,7 +724,7 @@ #endif /* USE_MMIO */ /* D-Link provided reset code (with comment additions) */ - if (rhine_chip_info[chip_id].drv_flags & HasWOL) { + if (quirks & rqWOL) { unsigned char byOrgValue; /* clear sticky bit before reset & read ethernet address */ @@ -726,7 +745,7 @@ writew(CmdReset, ioaddr + ChipCmd); dev->base_addr = ioaddr; - wait_for_reset(dev, chip_id, shortname); + wait_for_reset(dev, quirks, shortname); /* Reload the station address from the EEPROM. */ #ifdef USE_MMIO @@ -734,7 +753,7 @@ /* Reloading from eeprom overwrites cfgA-D, so we must re-enable MMIO. If reload_eeprom() was done first this could be avoided, but it is not known if that still works with the "win98-reboot" problem. */ - enable_mmio(ioaddr0, chip_id); + enable_mmio(ioaddr0, quirks); #else reload_eeprom(ioaddr); #endif @@ -748,7 +767,7 @@ goto err_out_unmap; } - if (chip_id == VT6102) { + if (quirks & rqWOL) { /* * for 3065D, EEPROM reloaded will cause bit 0 in MAC_REG_CFGA * turned on. it makes MAC receive magic packet @@ -766,9 +785,8 @@ rp = netdev_priv(dev); spin_lock_init(&rp->lock); - rp->chip_id = chip_id; - rp->drv_flags = rhine_chip_info[chip_id].drv_flags; rp->pdev = pdev; + rp->quirks = quirks; rp->mii_if.dev = dev; rp->mii_if.mdio_read = mdio_read; rp->mii_if.mdio_write = mdio_write; @@ -791,7 +809,7 @@ #ifdef CONFIG_NET_POLL_CONTROLLER dev->poll_controller = rhine_poll; #endif - if (rp->drv_flags & ReqTxAlign) + if (rp->quirks & rqRhineI) dev->features |= NETIF_F_SG|NETIF_F_HW_CSUM; /* dev->name not defined before register_netdev()! */ @@ -813,8 +831,8 @@ rp->mii_if.force_media = 1; } - printk(KERN_INFO "%s: %s at 0x%lx, ", - dev->name, rhine_chip_info[chip_id].name, + printk(KERN_INFO "%s: VIA %s at 0x%lx, ", + dev->name, name, #ifdef USE_MMIO memaddr #else @@ -896,7 +914,7 @@ printk(KERN_ERR "Could not allocate DMA memory.\n"); return -ENOMEM; } - if (rp->drv_flags & ReqTxAlign) { + if (rp->quirks & rqRhineI) { rp->tx_bufs = pci_alloc_consistent(rp->pdev, PKT_BUF_SZ * TX_RING_SIZE, &rp->tx_bufs_dma); @@ -1154,7 +1172,7 @@ return i; alloc_rbufs(dev); alloc_tbufs(dev); - wait_for_reset(dev, rp->chip_id, dev->name); + wait_for_reset(dev, rp->quirks, dev->name); init_registers(dev); if (debug > 2) printk(KERN_DEBUG "%s: Done rhine_open(), status %4.4x " @@ -1260,7 +1278,7 @@ alloc_rbufs(dev); /* Reinitialize the hardware. */ - wait_for_reset(dev, rp->chip_id, dev->name); + wait_for_reset(dev, rp->quirks, dev->name); init_registers(dev); spin_unlock(&rp->lock); @@ -1291,7 +1309,7 @@ rp->tx_skbuff[entry] = skb; - if ((rp->drv_flags & ReqTxAlign) && + if ((rp->quirks & rqRhineI) && (((long)skb->data & 3) || skb_shinfo(skb)->nr_frags != 0 || skb->ip_summed == CHECKSUM_HW)) { /* Must use alignment buffer. */ if (skb->len > PKT_BUF_SZ) { @@ -1440,7 +1458,7 @@ if (txstatus & 0x0200) rp->stats.tx_window_errors++; if (txstatus & 0x0100) rp->stats.tx_aborted_errors++; if (txstatus & 0x0080) rp->stats.tx_heartbeat_errors++; - if (((rp->chip_id == VT86C100A) && txstatus & 0x0002) || + if (((rp->quirks & rqRhineI) && txstatus & 0x0002) || (txstatus & 0x0800) || (txstatus & 0x1000)) { rp->stats.tx_fifo_errors++; rp->tx_ring[entry].tx_status = cpu_to_le32(DescOwn); @@ -1448,7 +1466,7 @@ } /* Transmitter restarted in 'abnormal' handler. */ } else { - if (rp->chip_id == VT86C100A) + if (rp->quirks & rqRhineI) rp->stats.collisions += (txstatus >> 3) & 0x0F; else rp->stats.collisions += txstatus & 0x0F; @@ -1660,7 +1678,7 @@ if (intr_status & (IntrLinkChange)) { if (readb(ioaddr + MIIStatus) & 0x02) { /* Link failed, restart autonegotiation. */ - if (rp->drv_flags & HasDavicomPhy) + if (rp->quirks & rqRhineI) mdio_write(dev, rp->phys[0], MII_BMCR, 0x3300); } else rhine_check_duplex(dev); From rl@hellgate.ch Wed Jun 2 04:59:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 04:59:46 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52Bxdgi011059 for ; Wed, 2 Jun 2004 04:59:40 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C00039939; Wed, 2 Jun 2004 11:59:21 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 25C048CA75E; Wed, 2 Jun 2004 13:59:20 +0200 (CEST) Date: Wed, 2 Jun 2004 13:59:20 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [9/9][PATCH 2.6] Restructure reset code Message-ID: <20040602115920.GA17634@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 6819 Lines: 268 Restructure code to make it easier to maintain. rhine_hw_init: resets chip, reloads eeprom rhine_chip_reset: chip reset + what used to be wait_for_reset rhine_reload_eeprom: reload eeprom, re-enable MMIO, disable EEPROM-controlled WOL Note: Chip reset clears a bunch of registers that should be reloaded from EEPROM (which turns off MMIO). Deal with that later. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -579,56 +579,76 @@ } } -static void wait_for_reset(struct net_device *dev, u32 quirks, char *name) +static void rhine_chip_reset(struct net_device *dev) { long ioaddr = dev->base_addr; + struct rhine_private *rp = netdev_priv(dev); int boguscnt = 20; + writew(CmdReset, ioaddr + ChipCmd); IOSYNC; if (readw(ioaddr + ChipCmd) & CmdReset) { printk(KERN_INFO "%s: Reset not complete yet. " - "Trying harder.\n", name); + "Trying harder.\n", DRV_NAME); - /* Rhine-II needs to be forced sometimes */ - if (quirks & rqForceReset) + /* Force reset */ + if (rp->quirks & rqForceReset) writeb(0x40, ioaddr + MiscCmd); - /* VT86C100A may need long delay after reset (dlink) */ - /* Seen on Rhine-II as well (rl) */ + /* Reset can take somewhat longer (rare) */ while ((readw(ioaddr + ChipCmd) & CmdReset) && --boguscnt) udelay(5); - } if (debug > 1) - printk(KERN_INFO "%s: Reset %s.\n", name, + printk(KERN_INFO "%s: Reset %s.\n", pci_name(rp->pdev), boguscnt ? "succeeded" : "failed"); } #ifdef USE_MMIO -static void __devinit enable_mmio(long ioaddr, u32 quirks) +static void __devinit enable_mmio(long pioaddr, u32 quirks) { int n; if (quirks & rqRhineI) { /* More recent docs say that this bit is reserved ... */ - n = inb(ioaddr + ConfigA) | 0x20; - outb(n, ioaddr + ConfigA); + n = inb(pioaddr + ConfigA) | 0x20; + outb(n, pioaddr + ConfigA); } else { - n = inb(ioaddr + ConfigD) | 0x80; - outb(n, ioaddr + ConfigD); + n = inb(pioaddr + ConfigD) | 0x80; + outb(n, pioaddr + ConfigD); } } #endif -static void __devinit reload_eeprom(long ioaddr) +/* + * Loads bytes 0x00-0x05, 0x6E-0x6F, 0x78-0x7B from EEPROM + */ +static void __devinit rhine_reload_eeprom(long pioaddr, struct net_device *dev) { + long ioaddr = dev->base_addr; + struct rhine_private *rp = netdev_priv(dev); int i; - outb(0x20, ioaddr + MACRegEEcsr); + + outb(0x20, pioaddr + MACRegEEcsr); /* Typically 2 cycles to reload. */ for (i = 0; i < 150; i++) - if (! (inb(ioaddr + MACRegEEcsr) & 0x20)) + if (! (inb(pioaddr + MACRegEEcsr) & 0x20)) break; + +#ifdef USE_MMIO + /* + * Reloading from EEPROM overwrites ConfigA-D, so we must re-enable + * MMIO. If reloading EEPROM was done first this could be avoided, but + * it is not known if that still works with the "win98-reboot" problem. + */ + enable_mmio(pioaddr, rp->quirks); +#endif + + /* Turn off EEPROM-controlled wake-up (magic packet) */ + if (rp->quirks & rqWOL) + writeb(readb(ioaddr + ConfigA) & 0xFE, ioaddr + ConfigA); + } #ifdef CONFIG_NET_POLL_CONTROLLER @@ -640,6 +660,15 @@ } #endif +static void rhine_hw_init(struct net_device *dev, long pioaddr) +{ + /* Reset the chip to erase previous misconfiguration. */ + rhine_chip_reset(dev); + + /* Reload EEPROM controlled bytes cleared by soft reset */ + rhine_reload_eeprom(pioaddr, dev); +} + static int __devinit rhine_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -649,13 +678,11 @@ u8 pci_rev; u32 quirks; static int card_idx = -1; - long ioaddr; + long pioaddr; long memaddr; + long ioaddr; int io_size; int phy, phy_idx = 0; -#ifdef USE_MMIO - long ioaddr0; -#endif const char *name; /* when built into the kernel, we only print version if device is found */ @@ -708,7 +735,7 @@ goto err_out; } - ioaddr = pci_resource_start(pdev, 0); + pioaddr = pci_resource_start(pdev, 0); memaddr = pci_resource_start(pdev, 1); pci_set_master(pdev); @@ -728,8 +755,7 @@ goto err_out_free_netdev; #ifdef USE_MMIO - ioaddr0 = ioaddr; - enable_mmio(ioaddr0, quirks); + enable_mmio(pioaddr, quirks); ioaddr = (long) ioremap(memaddr, io_size); if (!ioaddr) { @@ -743,7 +769,7 @@ i = 0; while (mmio_verify_registers[i]) { int reg = mmio_verify_registers[i++]; - unsigned char a = inb(ioaddr0+reg); + unsigned char a = inb(pioaddr+reg); unsigned char b = readb(ioaddr+reg); if (a != b) { rc = -EIO; @@ -752,26 +778,18 @@ goto err_out_unmap; } } +#else + ioaddr = pioaddr; #endif /* USE_MMIO */ + dev->base_addr = ioaddr; + rp = netdev_priv(dev); + rp->quirks = quirks; rhine_power_init(dev); /* Reset the chip to erase previous misconfiguration. */ - writew(CmdReset, ioaddr + ChipCmd); - - wait_for_reset(dev, quirks, shortname); - - /* Reload the station address from the EEPROM. */ -#ifdef USE_MMIO - reload_eeprom(ioaddr0); - /* Reloading from eeprom overwrites cfgA-D, so we must re-enable MMIO. - If reload_eeprom() was done first this could be avoided, but it is - not known if that still works with the "win98-reboot" problem. */ - enable_mmio(ioaddr0, quirks); -#else - reload_eeprom(ioaddr); -#endif + rhine_hw_init(dev, pioaddr); for (i = 0; i < 6; i++) dev->dev_addr[i] = readb(ioaddr + StationAddr + i); @@ -782,15 +800,6 @@ goto err_out_unmap; } - if (quirks & rqWOL) { - /* - * for 3065D, EEPROM reloaded will cause bit 0 in MAC_REG_CFGA - * turned on. it makes MAC receive magic packet - * automatically. So, we turn it off. (D-Link) - */ - writeb(readb(ioaddr + ConfigA) & 0xFE, ioaddr + ConfigA); - } - /* Select backoff algorithm */ if (backoff) writeb(readb(ioaddr + ConfigD) & (0xF0 | backoff), @@ -798,10 +807,8 @@ dev->irq = pdev->irq; - rp = netdev_priv(dev); spin_lock_init(&rp->lock); rp->pdev = pdev; - rp->quirks = quirks; rp->mii_if.dev = dev; rp->mii_if.mdio_read = mdio_read; rp->mii_if.mdio_write = mdio_write; @@ -1170,9 +1177,6 @@ long ioaddr = dev->base_addr; int i; - /* Reset the chip. */ - writew(CmdReset, ioaddr + ChipCmd); - i = request_irq(rp->pdev->irq, &rhine_interrupt, SA_SHIRQ, dev->name, dev); if (i) @@ -1187,7 +1191,7 @@ return i; alloc_rbufs(dev); alloc_tbufs(dev); - wait_for_reset(dev, rp->quirks, dev->name); + rhine_chip_reset(dev); init_registers(dev); if (debug > 2) printk(KERN_DEBUG "%s: Done rhine_open(), status %4.4x " @@ -1283,9 +1287,6 @@ spin_lock(&rp->lock); - /* Reset the chip. */ - writew(CmdReset, ioaddr + ChipCmd); - /* clear all descriptors */ free_tbufs(dev); free_rbufs(dev); @@ -1293,7 +1294,7 @@ alloc_rbufs(dev); /* Reinitialize the hardware. */ - wait_for_reset(dev, rp->quirks, dev->name); + rhine_chip_reset(dev); init_registers(dev); spin_unlock(&rp->lock); From rl@hellgate.ch Wed Jun 2 05:33:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 05:33:33 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52CXSgi012241 for ; Wed, 2 Jun 2004 05:33:29 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A68002308C2; Wed, 2 Jun 2004 11:59:06 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id B41E28CA75E; Wed, 2 Jun 2004 13:59:06 +0200 (CEST) Date: Wed, 2 Jun 2004 13:59:06 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [8/9][PATCH 2.6] Add rhine_power_init(): get power regs into sane state Message-ID: <20040602115906.GA17612@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 2645 Lines: 92 Add rhine_power_init(): get power regs into sane state. Move the respective code out of rhine_init_one. Add code for two additional patterns (Rhine III). Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -408,8 +408,10 @@ MIICmd=0x70, MIIRegAddr=0x71, MIIData=0x72, MACRegEEcsr=0x74, ConfigA=0x78, ConfigB=0x79, ConfigC=0x7A, ConfigD=0x7B, RxMissed=0x7C, RxCRCErrs=0x7E, MiscCmd=0x81, - StickyHW=0x83, IntrStatus2=0x84, WOLcrClr=0xA4, WOLcgClr=0xA7, - PwrcsrClr=0xAC, + StickyHW=0x83, IntrStatus2=0x84, + WOLcrSet=0xA0, WOLcrClr=0xA4, WOLcrClr1=0xA6, + WOLcgClr=0xA7, + PwrcsrSet=0xA8, PwrcsrSet1=0xA9, PwrcsrClr=0xAC, PwrcsrClr1=0xAD, }; /* Bits in ConfigD */ @@ -548,6 +550,35 @@ return intr_status; } +/* + * Get power related registers into sane state. + * Returns content of power-event (WOL) registers. + */ +static void rhine_power_init(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + struct rhine_private *rp = netdev_priv(dev); + + if (rp->quirks & rqWOL) { + /* Make sure chip is in power state D0 */ + writeb(readb(ioaddr + StickyHW) & 0xFC, ioaddr + StickyHW); + + /* Disable "force PME-enable" */ + writeb(0x80, ioaddr + WOLcgClr); + + /* Clear power-event config bits (WOL) */ + writeb(0xFF, ioaddr + WOLcrClr); + /* More recent cards can manage two additional patterns */ + if (rp->quirks & rq6patterns) + writeb(0x03, ioaddr + WOLcrClr1); + + /* Clear power-event status bits */ + writeb(0xFF, ioaddr + PwrcsrClr); + if (rp->quirks & rq6patterns) + writeb(0x03, ioaddr + PwrcsrClr1); + } +} + static void wait_for_reset(struct net_device *dev, u32 quirks, char *name) { long ioaddr = dev->base_addr; @@ -722,29 +753,13 @@ } } #endif /* USE_MMIO */ + dev->base_addr = ioaddr; - /* D-Link provided reset code (with comment additions) */ - if (quirks & rqWOL) { - unsigned char byOrgValue; - - /* clear sticky bit before reset & read ethernet address */ - byOrgValue = readb(ioaddr + StickyHW); - byOrgValue = byOrgValue & 0xFC; - writeb(byOrgValue, ioaddr + StickyHW); - - /* (bits written are cleared?) */ - /* disable force PME-enable */ - writeb(0x80, ioaddr + WOLcgClr); - /* disable power-event config bit */ - writeb(0xFF, ioaddr + WOLcrClr); - /* clear power status (undocumented in vt6102 docs?) */ - writeb(0xFF, ioaddr + PwrcsrClr); - } + rhine_power_init(dev); /* Reset the chip to erase previous misconfiguration. */ writew(CmdReset, ioaddr + ChipCmd); - dev->base_addr = ioaddr; wait_for_reset(dev, quirks, shortname); /* Reload the station address from the EEPROM. */ From jm@jm.kir.nu Wed Jun 2 06:24:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 06:24:42 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52DObgi013821 for ; Wed, 2 Jun 2004 06:24:37 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BVVi6-0001zJ-8R; Wed, 02 Jun 2004 06:23:14 -0700 Date: Wed, 2 Jun 2004 06:23:14 -0700 From: Jouni Malinen To: "Luis R. Rodriguez" Cc: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040602132313.GB7341@jm.kir.nu> Mail-Followup-To: "Luis R. Rodriguez" , Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel References: <20040602071449.GJ10723@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602071449.GJ10723@ruslug.rutgers.edu> User-Agent: Mutt/1.5.6i X-archive-position: 5548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 2229 Lines: 41 On Wed, Jun 02, 2004 at 03:14:49AM -0400, Luis R. Rodriguez wrote: > I'm glad wpa_supplicant exists :). Interacting with it *is* our missing > link to getting full WPA support (great job Jouni). In wpa_supplicant > cvs I see a base code for driver_prism54.c (empty routines, just providing skeleton). > Well I'll be diving in it now and see where I can get. If anyone else is > interested in helping with WPA support for prism54, working with > wpa_supplicant is the way to go. I have a bit more code for this in my work directory somewhere (setting the WPA IE and a new ioctl for this for the driver). I did not submit these yet since the extended MLME mode was not working and the changes were not yet really working properly. I can try to find these patches somewhere.. Anyway, I would first like to see the extended MLME mode working with any (even plaintext) AP and then somehow add the WPA IE to the AssocReq. After that, it should be only TKIP/CCMP key configuration and that's about it.. > I'm curious though -- wpa_supplicant is pretty much userspace. This was > done with good intentions from what I read but before we get dirty > with wpa_supplicant I'm wondering if we should just integrate a lot of > wpa_supplicant into kernel space (specifically wireless tools). Why? Which functionality would you like to move into kernel? Not that I'm against moving some parts, but I would certainly like to hear good reasons whenever moving something to kernel space if it can be done (or in this case, has already been done) in user space.. > Regardless, as Jouni points out, there is still a framework for WPA that needs > to be written for all linux wireless drivers, whether it's to assist > wpa_supplicant framework or to integrate wpa_supplicant into kernel space. The first thing I would like to see is an addition to Linux wireless extensions for WPA/WPA2 so that we can get rid of the private ioctls in the drivers. Even though these can often be similar, it would be nice to just write one driver interface code in wpa_supplicant and have it working with all Linu drivers.. I hope to find some time to write a proposal for this. -- Jouni Malinen PGP id EFC895FA From rl@hellgate.ch Wed Jun 2 06:34:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 06:34:05 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52DY2gi014357 for ; Wed, 2 Jun 2004 06:34:03 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C00039683; Wed, 2 Jun 2004 11:57:03 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 061978CA75E; Wed, 2 Jun 2004 13:57:04 +0200 (CEST) Date: Wed, 2 Jun 2004 13:57:03 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [0/9][2.6] via-rhine patches Message-ID: <20040602115703.GA16079@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 431 Lines: 11 More changes for via-rhine, part of my clean-up effort to make via-rhine easier to maintain. After this batch, I have a few clean-up patches that are a tad more intrusive, plus fixes for broken functionality and new features. Big thanks to A.J. from VIA Networking Technologies, Inc. who has provided detailed information on Rhine chip behavior. Without him, many of the via-rhine patches to come would not have happened. Roger From rl@hellgate.ch Wed Jun 2 07:03:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 07:03:33 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52E3Sgi015303 for ; Wed, 2 Jun 2004 07:03:29 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A680023080D; Wed, 2 Jun 2004 11:58:06 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 3099B8CA75E; Wed, 2 Jun 2004 13:58:06 +0200 (CEST) Date: Wed, 2 Jun 2004 13:58:06 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [2/9][PATCH 2.6] Nuke CanHaveMII and related code Message-ID: <20040602115805.GA17418@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 3474 Lines: 134 All Rhines can have a MII. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -375,7 +375,7 @@ enum chip_capability_flags { - CanHaveMII=1, HasESIPhy=2, HasDavicomPhy=4, + HasESIPhy=2, HasDavicomPhy=4, ReqTxAlign=0x10, HasWOL=0x20, }; @@ -391,13 +391,13 @@ static struct rhine_chip_info rhine_chip_info[] __devinitdata = { { "VIA VT86C100A Rhine", RHINE_IOTYPE, 128, - CanHaveMII | ReqTxAlign | HasDavicomPhy }, + ReqTxAlign | HasDavicomPhy }, { "VIA VT6102 Rhine-II", RHINE_IOTYPE, 256, - CanHaveMII | HasWOL }, + HasWOL }, { "VIA VT6105 Rhine-III", RHINE_IOTYPE, 256, - CanHaveMII | HasWOL }, + HasWOL }, { "VIA VT6105M Rhine-III", RHINE_IOTYPE, 256, - CanHaveMII | HasWOL }, + HasWOL }, }; static struct pci_device_id rhine_pci_tbl[] = @@ -635,6 +635,7 @@ long memaddr; int io_size; int pci_flags; + int phy, phy_idx = 0; #ifdef USE_MMIO long ioaddr0; #endif @@ -830,32 +831,29 @@ pci_set_drvdata(pdev, dev); - if (rp->drv_flags & CanHaveMII) { - int phy, phy_idx = 0; - rp->phys[0] = 1; /* Standard for this chip. */ - for (phy = 1; phy < 32 && phy_idx < MAX_MII_CNT; phy++) { - int mii_status = mdio_read(dev, phy, 1); - if (mii_status != 0xffff && mii_status != 0x0000) { - rp->phys[phy_idx++] = phy; - rp->mii_if.advertising = mdio_read(dev, phy, 4); - printk(KERN_INFO "%s: MII PHY found at address " - "%d, status 0x%4.4x advertising %4.4x " - "Link %4.4x.\n", dev->name, phy, - mii_status, rp->mii_if.advertising, - mdio_read(dev, phy, 5)); - - /* set IFF_RUNNING */ - if (mii_status & BMSR_LSTATUS) - netif_carrier_on(dev); - else - netif_carrier_off(dev); + rp->phys[0] = 1; /* Standard for this chip. */ + for (phy = 1; phy < 32 && phy_idx < MAX_MII_CNT; phy++) { + int mii_status = mdio_read(dev, phy, 1); + if (mii_status != 0xffff && mii_status != 0x0000) { + rp->phys[phy_idx++] = phy; + rp->mii_if.advertising = mdio_read(dev, phy, 4); + printk(KERN_INFO "%s: MII PHY found at address " + "%d, status 0x%4.4x advertising %4.4x " + "Link %4.4x.\n", dev->name, phy, + mii_status, rp->mii_if.advertising, + mdio_read(dev, phy, 5)); + + /* set IFF_RUNNING */ + if (mii_status & BMSR_LSTATUS) + netif_carrier_on(dev); + else + netif_carrier_off(dev); - break; - } + break; } - rp->mii_cnt = phy_idx; - rp->mii_if.phy_id = rp->phys[0]; } + rp->mii_cnt = phy_idx; + rp->mii_if.phy_id = rp->phys[0]; /* Allow forcing the media type. */ if (option > 0) { @@ -1800,9 +1798,6 @@ struct rhine_private *rp = netdev_priv(dev); int rc; - if (!(rp->drv_flags & CanHaveMII)) - return -EINVAL; - spin_lock_irq(&rp->lock); rc = mii_ethtool_gset(&rp->mii_if, cmd); spin_unlock_irq(&rp->lock); @@ -1815,9 +1810,6 @@ struct rhine_private *rp = netdev_priv(dev); int rc; - if (!(rp->drv_flags & CanHaveMII)) - return -EINVAL; - spin_lock_irq(&rp->lock); rc = mii_ethtool_sset(&rp->mii_if, cmd); spin_unlock_irq(&rp->lock); @@ -1829,9 +1821,6 @@ { struct rhine_private *rp = netdev_priv(dev); - if (!(rp->drv_flags & CanHaveMII)) - return -EINVAL; - return mii_nway_restart(&rp->mii_if); } @@ -1839,9 +1828,6 @@ { struct rhine_private *rp = netdev_priv(dev); - if (!(rp->drv_flags & CanHaveMII)) - return 0; /* -EINVAL */ - return mii_link_ok(&rp->mii_if); } From rl@hellgate.ch Wed Jun 2 07:29:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 07:29:51 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52ETggi016391 for ; Wed, 2 Jun 2004 07:29:42 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD30022DD38; Wed, 2 Jun 2004 11:58:42 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 8949D8CA75E; Wed, 2 Jun 2004 13:58:42 +0200 (CEST) Date: Wed, 2 Jun 2004 13:58:42 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [5/9][PATCH 2.6] Nuke all pci_flags Message-ID: <20040602115842.GA17533@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 2342 Lines: 98 All this code together can be replaced with a single #ifdef USE_MMIO. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -354,11 +354,6 @@ second only the 1234 card. */ -enum pci_flags_bit { - PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4, - PCI_ADDR0=0x10<<0, PCI_ADDR1=0x10<<1, PCI_ADDR2=0x10<<2, PCI_ADDR3=0x10<<3, -}; - enum rhine_chips { VT86C100A = 0, VT6102, @@ -368,7 +363,6 @@ struct rhine_chip_info { const char *name; - u16 pci_flags; int io_size; int drv_flags; }; @@ -379,24 +373,19 @@ ReqTxAlign=0x10, HasWOL=0x20, }; -#ifdef USE_MMIO -#define RHINE_IOTYPE (PCI_USES_MEM | PCI_USES_MASTER | PCI_ADDR1) -#else -#define RHINE_IOTYPE (PCI_USES_IO | PCI_USES_MASTER | PCI_ADDR0) -#endif /* Beware of PCI posted writes */ #define IOSYNC do { readb(dev->base_addr + StationAddr); } while (0) /* directly indexed by enum rhine_chips, above */ static struct rhine_chip_info rhine_chip_info[] __devinitdata = { - { "VIA VT86C100A Rhine", RHINE_IOTYPE, 128, + { "VIA VT86C100A Rhine", 128, ReqTxAlign | HasDavicomPhy }, - { "VIA VT6102 Rhine-II", RHINE_IOTYPE, 256, + { "VIA VT6102 Rhine-II", 256, HasWOL }, - { "VIA VT6105 Rhine-III", RHINE_IOTYPE, 256, + { "VIA VT6105 Rhine-III", 256, HasWOL }, - { "VIA VT6105M Rhine-III", RHINE_IOTYPE, 256, + { "VIA VT6105M Rhine-III", 256, HasWOL }, }; @@ -633,7 +622,6 @@ long ioaddr; long memaddr; int io_size; - int pci_flags; int phy, phy_idx = 0; #ifdef USE_MMIO long ioaddr0; @@ -649,7 +637,6 @@ card_idx++; option = card_idx < MAX_UNITS ? options[card_idx] : 0; io_size = rhine_chip_info[chip_id].io_size; - pci_flags = rhine_chip_info[chip_id].pci_flags; if (pci_enable_device(pdev)) goto err_out; @@ -671,8 +658,7 @@ ioaddr = pci_resource_start(pdev, 0); memaddr = pci_resource_start(pdev, 1); - if (pci_flags & PCI_USES_MASTER) - pci_set_master(pdev); + pci_set_master(pdev); dev = alloc_etherdev(sizeof(*rp)); if (dev == NULL) { @@ -821,7 +807,12 @@ printk(KERN_INFO "%s: %s at 0x%lx, ", dev->name, rhine_chip_info[chip_id].name, - (pci_flags & PCI_USES_IO) ? ioaddr : memaddr); +#ifdef USE_MMIO + memaddr +#else + ioaddr +#endif + ); for (i = 0; i < 5; i++) printk("%2.2x:", dev->dev_addr[i]); From sam@errno.com Wed Jun 2 09:32:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 09:32:11 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52GW5gi016917 for ; Wed, 2 Jun 2004 09:32:07 -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 i52GW1WR035169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 2 Jun 2004 09:32:02 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: hostap@shmoo.com Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Date: Wed, 2 Jun 2004 09:28:07 -0700 User-Agent: KMail/1.6.1 Cc: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez), Netdev , prism54-devel@prism54.org, Jean Tourrilhes , Linux Kernel , Jeff Garzik References: <20040602071449.GJ10723@ruslug.rutgers.edu> In-Reply-To: <20040602071449.GJ10723@ruslug.rutgers.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406020928.07513.sam@errno.com> X-archive-position: 5555 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: 1907 Lines: 35 On Wednesday 02 June 2004 12:14 am, Luis R. Rodriguez wrote: > So WPA is now a priority for prism54 development. Here's where we're at. > Long ago in January Jouni had added some wpa supplicant support into > prism54. It's not until today when I started looking into > wpa_supplicant. > > I'm glad wpa_supplicant exists :). Interacting with it *is* our missing > link to getting full WPA support (great job Jouni). In wpa_supplicant > cvs I see a base code for driver_prism54.c (empty routines, just providing > skeleton). Well I'll be diving in it now and see where I can get. If anyone > else is interested in helping with WPA support for prism54, working with > wpa_supplicant is the way to go. > > I'm curious though -- wpa_supplicant is pretty much userspace. This was > done with good intentions from what I read but before we get dirty > with wpa_supplicant I'm wondering if we should just integrate a lot of > wpa_supplicant into kernel space (specifically wireless tools). > Regardless, as Jouni points out, there is still a framework for WPA that > needs to be written for all linux wireless drivers, whether it's to assist > wpa_supplicant framework or to integrate wpa_supplicant into kernel space. > > What's the plan? I think wpa_supplicant takes the right approach (i.e. putting the majority of the code in user space). The supplicant is not performance intensive and there's little justification for it going in the kernel on other grounds (like security). I've had madwifi working with wpa_supplicant for quite a while and have also done a rough port of wpa_supplicant to the bsd world too so it's design is proven (and in general I think it's excellent work). I'd second Jouni's comments about moving the wireless extensions support forward. Aside from WPA there are a few private mechanisms required for multi-mode devices that should be handled through a standard API. Sam From rl@hellgate.ch Wed Jun 2 09:33:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 09:33:32 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52GXSgi017454 for ; Wed, 2 Jun 2004 09:33:29 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A68002307E2; Wed, 2 Jun 2004 11:57:54 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 8D7048CA75E; Wed, 2 Jun 2004 13:57:54 +0200 (CEST) Date: Wed, 2 Jun 2004 13:57:54 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [1/9][PATCH 2.6] Nuke HAS_IP_COPYSUM Message-ID: <20040602115754.GA17396@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 703 Lines: 25 HAS_IP_COPYSUM has been utterly meaningless for a long time. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -1563,15 +1563,10 @@ eth_copy_and_sum is memcpy for all archs so this is kind of pointless right now ... or? */ -#if HAS_IP_COPYSUM /* Call copy + cksum if available. */ eth_copy_and_sum(skb, rp->rx_skbuff[entry]->tail, pkt_len, 0); skb_put(skb, pkt_len); -#else - memcpy(skb_put(skb, pkt_len), - rp->rx_skbuff[entry]->tail, pkt_len); -#endif pci_dma_sync_single_for_device(rp->pdev, rp->rx_skbuff_dma[entry], rp->rx_buf_sz, From mcgrof@studorgs.rutgers.edu Wed Jun 2 09:34:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 09:34:06 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52GXpgi017631 for ; Wed, 2 Jun 2004 09:33:51 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id E6BC6F9D4B; Wed, 2 Jun 2004 11:55:42 -0400 (EDT) Date: Wed, 2 Jun 2004 11:55:42 -0400 To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040602155542.GC24822@ruslug.rutgers.edu> Mail-Followup-To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline In-Reply-To: <20040602132313.GB7341@jm.kir.nu> 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: 5557 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: 3404 Lines: 81 --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 02, 2004 at 06:23:14AM -0700, Jouni Malinen wrote: > On Wed, Jun 02, 2004 at 03:14:49AM -0400, Luis R. Rodriguez wrote: >=20 > > I'm glad wpa_supplicant exists :). Interacting with it *is* our missing > > link to getting full WPA support (great job Jouni). In wpa_supplicant= =20 > > cvs I see a base code for driver_prism54.c (empty routines, just provid= ing skeleton). > > Well I'll be diving in it now and see where I can get. If anyone else is > > interested in helping with WPA support for prism54, working with > > wpa_supplicant is the way to go. >=20 > I have a bit more code for this in my work directory somewhere (setting > the WPA IE and a new ioctl for this for the driver). I did not submit > these yet since the extended MLME mode was not working and the changes > were not yet really working properly. I can try to find these patches > somewhere.. Anyway, I would first like to see the extended MLME mode > working with any (even plaintext) AP and then somehow add the WPA IE to > the AssocReq. After that, it should be only TKIP/CCMP key configuration > and that's about it.. If you find the patches that'd be great :). I'll see what I can do about fixing up extended MLME. I'll keep you posted.=20 > > I'm curious though -- wpa_supplicant is pretty much userspace. This was > > done with good intentions from what I read but before we get dirty=20 > > with wpa_supplicant I'm wondering if we should just integrate a lot of= =20 > > wpa_supplicant into kernel space (specifically wireless tools). >=20 > Why? Which functionality would you like to move into kernel? Not that > I'm against moving some parts, but I would certainly like to hear good > reasons whenever moving something to kernel space if it can be done (or > in this case, has already been done) in user space.. I have yet to review most of the wpa_supplicant code so I cannot say for sure yet what I think should go into the kernel. I e-mailed most lists mainly to get comments from others who have poked at wpa_supplicant and/or are looking into adding WPA client support into their drivers. I just wanted to make sure we were heading in the right direction since I only see 2 drivers that are currently using wpa_supplicant. > > Regardless, as Jouni points out, there is still a framework for WPA tha= t needs > > to be written for all linux wireless drivers, whether it's to assist > > wpa_supplicant framework or to integrate wpa_supplicant into kernel spa= ce. >=20 > The first thing I would like to see is an addition to Linux wireless > extensions for WPA/WPA2 so that we can get rid of the private ioctls in > the drivers. Even though these can often be similar, it would be nice to > just write one driver interface code in wpa_supplicant and have it > working with all Linu drivers.. I hope to find some time to write a > proposal for this. I agree :). Jean? *poke* Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --yNb1oOkm5a9FJOVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAvfh+at1JN+IKUl4RArobAJ90VhiqoBhMVDqVYNyrSVF7/oCWpwCcCgMw BNTyXala+SrO9iduCpBy7CQ= =FuH1 -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX-- From rl@hellgate.ch Wed Jun 2 11:34:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 11:34:09 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52IY2gi022962 for ; Wed, 2 Jun 2004 11:34:03 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C00039807; Wed, 2 Jun 2004 11:58:18 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id B0E238DFAEA; Wed, 2 Jun 2004 13:58:18 +0200 (CEST) Date: Wed, 2 Jun 2004 13:58:18 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [3/9][PATCH 2.6] Nuke HasESIPhy and related code Message-ID: <20040602115818.GA17462@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 716 Lines: 28 This has been dead code forever. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -375,7 +375,7 @@ enum chip_capability_flags { - HasESIPhy=2, HasDavicomPhy=4, + HasDavicomPhy=4, ReqTxAlign=0x10, HasWOL=0x20, }; @@ -1085,9 +1085,8 @@ /* The LED outputs of various MII xcvrs should be configured. */ /* For NS or Mison phys, turn on bit 1 in register 0x17 */ - /* For ESI phys, turn on bit 7 in register 0x17. */ mdio_write(dev, rp->phys[0], 0x17, mdio_read(dev, rp->phys[0], 0x17) | - (rp->drv_flags & HasESIPhy) ? 0x0080 : 0x0001); + 0x0001); } /* Read and write over the MII Management Data I/O (MDIO) interface. */ From margitsw@t-online.de Wed Jun 2 11:56:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 11:56:33 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52IuWgi023699 for ; Wed, 2 Jun 2004 11:56:32 -0700 Received: from fwd05.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1BUWZZ-0000ar-00; Sun, 30 May 2004 22:06:21 +0200 Received: from margit.t-online.de (TtKdIrZSwe9NSlkPb49k25BepXPTyFeZC6PZyh7VmZ6W+f+kt-5G0I@[80.128.220.231]) by fwd05.sul.t-online.com with esmtp id 1BUWZX-0oGeJc0; Sun, 30 May 2004 22:06:19 +0200 Message-Id: <5.1.0.14.2.20040530211258.00ae3b70@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 May 2004 22:07:15 +0200 To: netdev@oss.sgi.com From: margitsw@t-online.de (Margit Schubert-While) Subject: [PATCH 0/17 linux-2.6.7-rc2] prism54: Bring prism54 up to sync Cc: jgarzik@pobox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Seen: false X-ID: TtKdIrZSwe9NSlkPb49k25BepXPTyFeZC6PZyh7VmZ6W+f+kt-5G0I X-archive-position: 5560 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: 1266 Lines: 26 Please apply the following patches to linux-2.6.7-rc2. These patches bring the kernel tree up to sync with prism54.org's 1.2 release. [PATCH 1/17 linux-2.6.7-rc1] prism54: delete cvs tags [PATCH 2/17 linux-2.6.7-rc1] prism54: add new private ioctls [PATCH 3/17 linux-2.6.7-rc1] prism54: reset card on tx_timeout [PATCH 4/17 linux-2.6.7-rc1] prism54: add iwspy support [PATCH 5/17 linux-2.6.7-rc1] prism54: add support for avs header in monitor mode [PATCH 6/17 linux-2.6.7-rc1] prism54: new prism54 kernel compatibility [PATCH 7/17 linux-2.6.7-rc1] prism54: Fix endian bug [PATCH 8/17 linux-2.6.7-rc1] prism54: Fix prism54.org bugs 74, 75 [PATCH 9/17 linux-2.6.7-rc1] prism54: Fix prism54.org bugs 39, 73 [PATCH 10/17 linux-2.6.7-rc1] prism54: Fix prism54.org bug 77; strengthened oid transaction [PATCH 11/17 linux-2.6.7-rc1] prism54: Don't allow mib reads while unconfigured [PATCH 12/17 linux-2.6.7-rc1] prism54: Start using likely/unlikely [PATCH 13/17 linux-2.6.7-rc1] prism54: Align skb data [PATCH 14/17 linux-2.6.7-rc1] prism54: Reduce verbosity [PATCH 15/17 linux-2.6.7-rc1] prism54: Fix channel stats; bump to 1.2 [PATCH 16/17 linux-2.6.7-rc1] prism54: Simplify firmware load call [PATCH 17/17 linux-2.6.7-rc1] prism54: White space and indent Margit From marc.herbert@free.fr Wed Jun 2 12:11:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 12:11:28 -0700 (PDT) Received: from relay03s.clb.oleane.net (relay03s.clb.oleane.net [213.56.31.144]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52JBFgi024864 for ; Wed, 2 Jun 2004 12:11:15 -0700 Received: from [10.0.0.3] ([194.2.198.253]) by relay03s.clb.oleane.net with ESMTP id i52JB3sE026871; Wed, 2 Jun 2004 21:11:09 +0200 Date: Wed, 2 Jun 2004 21:11:04 +0200 (CEST) From: Marc Herbert X-X-Sender: mherbert@fcat To: Ricardo C Gonzalez cc: netdev@oss.sgi.com Subject: Re: [e1000 2.6 10/11] TxDescriptors -> 1024 default In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by relay03s.clb.oleane.net id i52JB3sE026871 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i52JBFgi024864 X-archive-position: 5561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc.herbert@free.fr Precedence: bulk X-list: netdev Content-Length: 1072 Lines: 29 On Tue, 18 May 2004, Ricardo C Gonzalez wrote: > Are you considering the case of small packets? Good point: I was not, because it adds some complexity :-/ > Many applications use > lots of small packets. Example is the volano benchmark. Well... isn't that example a bit extreme, rather than representative? > You needs to look at throughput rates for small packets. A 1GB ethernet > can send something like 1.4 Million 64 byte packets per second. > > Let me know what you think. I said in some previous message that, from the point of view of IP "applications" in the very broad sense (i.e., including TCP) the txqueuelen should ideally be defined in milliseconds, in order to give an upper bound to latency. I reiterate that. So, for a given Ethernet link _speed_, this would translates into an ideal definition of txqueuelen in _bytes_ and not in _packets_. The current approximation (in packets) seems to assume that people wishing to send a whole lot of small packets are seldom, and can set the txqueuelen by themselves. This seems sensible to me. From marc.herbert@free.fr Wed Jun 2 12:14:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 12:14:38 -0700 (PDT) Received: from relay02s.clb.oleane.net (relay02s.clb.oleane.net [213.56.31.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52JEVgi025204 for ; Wed, 2 Jun 2004 12:14:32 -0700 Received: from [10.0.0.3] ([194.2.198.253]) by relay02s.clb.oleane.net with ESMTP id i52JENC0003387; Wed, 2 Jun 2004 21:14:23 +0200 Date: Wed, 2 Jun 2004 21:14:24 +0200 (CEST) From: Marc Herbert X-X-Sender: mherbert@fcat To: "Brandeburg, Jesse" cc: netdev@oss.sgi.com Subject: RE: TxDescriptors -> 1024 default. Please not for every NIC! In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by relay02s.clb.oleane.net id i52JENC0003387 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i52JEVgi025204 X-archive-position: 5562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc.herbert@free.fr Precedence: bulk X-list: netdev Content-Length: 8512 Lines: 201 On Wed, 26 May 2004, Brandeburg, Jesse wrote: > I'm not sure that you could actually get the problem to occur on 100 > or 10Mb/s hardware however because of TCP window size limitation and > such. What I'm getting at is that even if you have a device that can > queue lots of packets, it probably won't unless you're using an > unreliable protocol like UDP. Theoretically it's a problem, but I'm > not convinced that in real world scenarios it actually creates any > issues. Do you have a test that demonstrates the problem? OK, let's go for it. The following message details a simple experiment demonstrating how a too big (1000-packet) txqueuelen creates a dreaded latency at the IP level inside the sender for under-gigabit Ethernet interfaces, and so finally advocates a default 1000-packet txqueuelen defined _only_ by/for the _GigE_ drivers, leaving the previous (before sep 2003 in 2.4) 100-packet default untouched for slower interfaces. The experiment should be very quick and easy to reproduce in your lab, even in your home. Sorry, this message is way too long because it's... detailed, and tries to anticipate questions, hopefully avoiding the need to come back on this issue. The counter-part is that it's not dense and thus hopefully quick to read for anyone in the field. And please pardon my english mistakes. Detailed Experiment ------------------- You need at least 2 hosts, but ideally 3. The sender "S", the receiver "R1", and some witness host "R2". R1 and R2can probably be collapsed together if you don't have enough hosts but I am afraid of unknown nasty side effects in this case. Host S is using a simple TCP connection to upload an infinite file to host R. The bottleneck is S's own 100Mb/s (or worst, 10Mb/s) network interface. This is very important: no packet drop must occur elsewhere between Sand R, else TCP congestion avoidance algorithm will interpret this as a congestion sign and throttle down, and the txqueue will stay empty. If your TCP connection is under-performing your sending wire for any reason, you will obviously never fill your txqueue. The ACK-clocking property of TCP has for consequence that only the queue of the bottleneck of the path may fill up (except in very dynamic environnements where the bottleneck may be fast-changing, but let's stay simple). Actually almost everything below is still true when the bottleneck is elsewhere in some router further on the path instead of local in the sender. It's still true, just... elsewhere. For instance if you use a linux box as a router, and if it happens to be the bottleneck, I suspect this latency issue will appear more or less the same. But again, let's stay simple for the moment, forget those further routers and get back to this _local_ IP bottleneck and its too big txqueuelen. By the way, forcing your GigE interface to 100 or 10is ok. I used iperf to upload the infinite file, but any equivalent tool should do it. Since your TCP connection will suffer this artificial txqueue latency, you also need to increase SND_BUF and RCV_BUF, else the number of TCP packets sent (and thus the txqueue filling) will be capped (wait below for more about this). - So just run: host_R $ iperf --server --interval 1 --window 1M host_S $ iperf --client R --time 1000 --window 1M Check that you get a full 94.1Mb/s (resp. 9.4Mb/s) wire-rate. If not, investigate why and don't bother going on. - Now just watch the latency between S some other host "R2". For instance using mtr: S$ mtr -l R2 As the txqueue fills up, you will see perceived latency increasing every round-trip time, up to 120ms (worst with 10Mb/s: up to 1.2s!). When the txqueue is full, TCP detects it and enters congestion window reduction, providing some temporary relief. Then the artificial latency quickly ramps up again. - You can also try to start another simultaneous upload to R2: host_R2 $ iperf -s -i 1 host_S $ iperf -c R2 -t 1000 ... and watch how the artificial latency harms the start of the other TCP connection, which need ages to ramp up it's throughput. I also heard from here: "A Map of the Networking Code in Linux Kernel 2.4.20", Technical Report DataTAG-2004-1, section 4.4 http://datatag.web.cern.ch/datatag/publications.html that you can get interesting qdisc stats using such commands: # tc qdisc add dev eth1 root pfifo limit 100 #tc -s -d qdisc show dev eth1 But I did not tried them. Warning: the interface tx_ring size has to be added to the qdisc's txqueuelen to get the total sender's queue length perceived by TCP. Some drivers may also set it big. Solution -------- Now reduce the txqueuelen to the previous value: ifconfig eth1 txqueuelen 100 for 10Mb/s you can even try: ifconfig eth1 txqueuelen 10 Now your latency is now back to a sensible value (12ms max), and everything works fine. It's a simple as that. Throughput is not harmed at all, you still get the full 94.1 Mb/s wire-rate. If this (previous) setting was harmful to throughput for 100Mb/s interfaces, people would have complained since long. The more complex truth ----------------------- If there is a real-world, distance-caused latency between S and R, then having some equivalent amount of buffering in txqueuelen helps average performance, because the interface has then a backlog of packets to send while TCP takes time to ramp up its congestion window again a decrease, the former compensating the latter. (This may be what the e1000 guys observed in the first place, motivating the increase to 1000? After all, 1.2ms of buffering was small) The txqueue may smooth the sawtooth evolution of TCP congestion window, minimizing the interface idle time. But increased perceived latency is the price to pay for this nice damper. There is a tradeoff between latency and TCPthroughput _on wide area_ routes to tune here, but pushing it as far as storing in txqueuelen _multiple_ times any real-world latency (did I say "1.2s" already?) brings no benefit at all for throughput; it's just terribly harmful for perceived latency. No IP router does so much buffering. Besides linux :-> I don't think IP queues should be sized to cope with moon-earth latency by default. Conclusion ---------- (aka: let's harass the maintainers) Of course I just demonstrated here the worst case. In many other cases, TCP will throttle down for some reason (packet losses, too small socket buffers,...), it will not fill the pipe nor the txqueue, and this dreaded latency will not appear. You could argue that my test case is very seldom in the real world/not representative (and I would _not_ agree), so the txqueue will never be full in practice, since there will always be some other reason making TCP under-performing the sending wire. OK. Even then, why defining it uselessly so highfor every NIC? Why take this risk? Just as a small convenience for e1000 users? Mmmmm... So now every interface has this 1000-packet queue (and soon 10,000 because of these upcoming 10Gb/s interfaces). To ensure no one ever falls in this too big txqueue trap, I suggest the following user documentation: "if you have a 100Mb/s interface, be warned that your txqueuelen is too high (it was tuned for real, gigabit men). So please reduce it using ifconfig. Alternatively, if you are not root, please tune your socket buffers finely. Too small, you will under-perform. Too big, you will fill up your txqueue and create artificial latency. Good luck. Of course, you can forget all the above when your interface is not the bottleneck" On the other hand, having a default max txqueuelen defined in _milliseconds_ (just like most other routers do) is quite easy to implement and covers correctly allcases, without complex tuning instructions for the end user. The ideal implementation is that every driver defines txqueuelen by itself, depending on the actual link speed. It is unrealistic in the short-term, but the incremental implementation path is very easy: define a "sensible, generic default" of100-packet, perfect for the 100Mb/s masses, not too bad for 10Mb/s masses, and let the (only few until now, let's hurry up) gigabit drivers override/optimize this to 1000, or whatever else even more finely tuned, for the cheap price of a few lines of code per driver. Thanks in advance for agreeing OR proving that I am wrong. I mean: thanks in advance for anything besides remaining silent. And thanks for reading all this gossiping, an impressive effort indeed. From jgarzik@pobox.com Wed Jun 2 12:41:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 12:41:28 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52JfIgi029056 for ; Wed, 2 Jun 2004 12:41:19 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVbbx-0002xj-GR; Wed, 02 Jun 2004 20:41:17 +0100 Message-ID: <40BE2D4F.3070005@pobox.com> Date: Wed, 02 Jun 2004 15:41:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Restructure reset code References: <20040602115920.GA17634@k3.hellgate.ch> In-Reply-To: <20040602115920.GA17634@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5563 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: 51 Lines: 2 applied patches 1 through 8, rejected 9 (for now) From chengjin@cs.caltech.edu Wed Jun 2 12:49:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 12:49:33 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52JnSgi029520 for ; Wed, 2 Jun 2004 12:49:30 -0700 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 1C844DF267; Wed, 2 Jun 2004 12:49:28 -0700 (PDT) Received: by fast2.cs.caltech.edu (Postfix, from userid 20269) id 854331FF02; Wed, 2 Jun 2004 12:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fast2.cs.caltech.edu (Postfix) with ESMTP id AA5FD1435EF; Wed, 2 Jun 2004 12:49:24 -0700 (PDT) Date: Wed, 2 Jun 2004 12:49:24 -0700 (PDT) From: Cheng Jin To: Marc Herbert Cc: "netdev@oss.sgi.com" Subject: RE: TxDescriptors -> 1024 default. Please not for every NIC! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-archive-position: 5564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Content-Length: 2731 Lines: 52 Marc, In general, I very much agree with what you have stated about not having a large txqueuelen. Txqueuelen should be something that alleviates the mismatch between CPU speed and NIC transmission speed, temporarily. As long as the txqueuelne is greater than zero, say 10 just to be safe, NIC will be running at full speed (unless there were inefficiencies in scheduling) so there is no incentive in setting it to be an excessively large value like 1000. > > I'm not sure that you could actually get the problem to occur on 100 > > or 10Mb/s hardware however because of TCP window size limitation and With today's CPU, I think you will be able to fill up the txqueuelen on a 10 or 100 Mbps NIC, assuming there is a large file transfer and large window size and stuff. > If there is a real-world, distance-caused latency between S and R, > then having some equivalent amount of buffering in txqueuelen helps > average performance, because the interface has then a backlog of > packets to send while TCP takes time to ramp up its congestion window > again a decrease, the former compensating the latter. (This may be > what the e1000 guys observed in the first place, motivating the > increase to 1000? After all, 1.2ms of buffering was small) The > txqueue may smooth the sawtooth evolution of TCP congestion window, > minimizing the interface idle time. But increased perceived latency > is the price to pay for this nice damper. There is a tradeoff between > latency and TCPthroughput _on wide area_ routes to tune here, but > pushing it as far as storing in txqueuelen _multiple_ times any > real-world latency (did I say "1.2s" already?) brings no benefit at > all for throughput; it's just terribly harmful for perceived latency. > No IP router does so much buffering. Besides linux :-> I don't think > IP queues should be sized to cope with moon-earth latency by default. Very much agree with this paragraph. As long as the buffer is more than one bandwidth delay product, for a single TCP flow, window halving after each loss will still sustain a large enough window to maintain packets in the buffer to have full utilization. The downside is exactly what Marc said, very very large queueing delay for a long time. Going back to what Marc said in an earlier e-mail about having txqueuelen in the unit of bytes rather than packets to provide a fixed queueing delay in ms rather than packets. Maintaining txqueuelen in ms would be an ideal solution, but probably hard to achieve in practice. Keeping txqueuelen in bytes may be a problem for senders that wants to send many small pacekts. While the byte count may be small, the overhead of sending small packets may introduce large delays. Cheng From jgarzik@pobox.com Wed Jun 2 12:56:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 12:56: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.12.10/8.12.9) with SMTP id i52Jubgi029933 for ; Wed, 2 Jun 2004 12:56:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVbqm-00036P-9T; Wed, 02 Jun 2004 20:56:36 +0100 Message-ID: <40BE30E8.3070002@pobox.com> Date: Wed, 02 Jun 2004 15:56:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While , Netdev Subject: Re: [PATCH 1/17 linux-2.6.7-rc2] prism54: delete cvs tags References: <200405310211.46049.margitsw@t-online.de> In-Reply-To: <200405310211.46049.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5565 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: 21 Lines: 2 applied patches 1-5 From jgarzik@pobox.com Wed Jun 2 13:11:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 13:11:50 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52KBkgi030634 for ; Wed, 2 Jun 2004 13:11:49 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVc5R-0003GI-Ek; Wed, 02 Jun 2004 21:11:45 +0100 Message-ID: <40BE3475.10301@pobox.com> Date: Wed, 02 Jun 2004 16:11:33 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: mcgrof@studorgs.rutgers.edu, Netdev Subject: Re: [2.6.7-rc2] prism54 patches References: <5.1.0.14.2.20040602095119.00aca6e0@pop.t-online.de> In-Reply-To: <5.1.0.14.2.20040602095119.00aca6e0@pop.t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5566 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: 174 Lines: 12 Margit Schubert-While wrote: > Hi Jeff, > Couple of questions. please send all questions also to mailing list. private mail only is discouraged. spread knowledge! Jeff From jgarzik@pobox.com Wed Jun 2 13:21:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 13:21:24 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52KLMgi031106 for ; Wed, 2 Jun 2004 13:21:22 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVcEh-0003M1-8X; Wed, 02 Jun 2004 21:21:19 +0100 Message-ID: <40BE36B3.5010907@pobox.com> Date: Wed, 02 Jun 2004 16:21:07 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krzysztof Halasa CC: netdev@oss.sgi.com Subject: Re: [PATCH] 2.6 Generic HDLC update References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5567 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 applied From jgarzik@pobox.com Wed Jun 2 13:24:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 13:24: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.12.10/8.12.9) with SMTP id i52KOcgi031484 for ; Wed, 2 Jun 2004 13:24:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVcHt-0003OK-1y; Wed, 02 Jun 2004 21:24:37 +0100 Message-ID: <40BE3778.1020404@pobox.com> Date: Wed, 02 Jun 2004 16:24:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: 3/x: [NETDRV] Add register_ei_netdev References: <20040313025859.GA8186@gondor.apana.org.au> <405C294D.5040508@pobox.com> <20040520111937.GA21804@gondor.apana.org.au> <20040522074435.GA9628@gondor.apana.org.au> <20040529084109.GA13032@gondor.apana.org.au> In-Reply-To: <20040529084109.GA13032@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5568 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: 301 Lines: 13 Herbert Xu wrote: > Hi Jeff: > > Here is the patch that adds register_ei_netdev which lets us get rid of > some of the duplicated printk's in the 8390 drivers. Patch looks OK, but I would prefer to reject it, and merge it later when an accompanying patch appears using this new function. Jeff From romieu@fr.zoreil.com Wed Jun 2 16:33:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 16:33:41 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52NXXgi014144 for ; Wed, 2 Jun 2004 16:33:34 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i52NVSuX022271; Thu, 3 Jun 2004 01:31:28 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i52NVS2p022270; Thu, 3 Jun 2004 01:31:28 +0200 Date: Thu, 3 Jun 2004 01:31:28 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, luto@myrealbox.com, netdev@oss.sgi.com Subject: [patch 2.6.7-rc2 + bk-netdev 1/4] r8169: link handling and phy reset rework Message-ID: <20040603013128.D18059@electric-eye.fr.zoreil.com> References: <200406010922.i519MIr27814@mail.osdl.org> <40BE2FAB.1040008@pobox.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: <40BE2FAB.1040008@pobox.com>; from jgarzik@pobox.com on Wed, Jun 02, 2004 at 03:51:07PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 5570 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: 8352 Lines: 283 Link handling changes (Andy Lutomirski ): - removed rtl8169_hw_phy_reset() and its busy loop; - RTL8169_PHY_TIMEOUT is x10 to account for the removal of the phy_link_down_cnt loop in rtl8169_phy_timer(); - added spinlocking in timer context for rtl8169_phy_timer to avoid messing with the {set/get}_settings commands issued via ethtool; - more TBI stuff. This patch differs from the former version on the following points: - the LinkChg irq does not enable the phy timer when the link goes down any more; - the phy timer is not enabled in rtl8169_set_speed(); - removal of the initial renegotiation hack. diff -puN drivers/net/r8169.c~r8169-link-00 drivers/net/r8169.c --- linux-2.6.7-rc2/drivers/net/r8169.c~r8169-link-00 2004-06-02 22:40:49.000000000 +0200 +++ linux-2.6.7-rc2-fr/drivers/net/r8169.c 2004-06-02 23:17:50.000000000 +0200 @@ -41,6 +41,7 @@ VERSION 1.2 <2002/11/30> #include #include #include +#include #include #include #include @@ -107,7 +108,7 @@ static int multicast_filter_limit = 32; #define RTL_MIN_IO_SIZE 0x80 #define RTL8169_TX_TIMEOUT (6*HZ) -#define RTL8169_PHY_TIMEOUT (HZ) +#define RTL8169_PHY_TIMEOUT (10*HZ) /* write/read MMIO register */ #define RTL_W8(reg, val8) writeb ((val8), ioaddr + (reg)) @@ -341,7 +342,6 @@ struct rtl8169_private { struct sk_buff *Rx_skbuff[NUM_RX_DESC]; /* Rx data buffers */ struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Tx data buffers */ struct timer_list timer; - unsigned long phy_link_down_cnt; u16 cp_cmd; u16 intr_mask; int phy_auto_nego_reg; @@ -349,6 +349,9 @@ struct rtl8169_private { int (*set_speed)(struct net_device *, u8 autoneg, u16 speed, u8 duplex); void (*get_settings)(struct net_device *, struct ethtool_cmd *); + void (*phy_reset_enable)(void *); + unsigned int (*phy_reset_pending)(void *); + unsigned int (*link_ok)(void *); }; MODULE_AUTHOR("Realtek"); @@ -374,7 +377,7 @@ static int rtl8169_poll(struct net_devic static const u16 rtl8169_intr_mask = LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const u16 rtl8169_napi_event = - RxOK | LinkChg | RxOverflow | RxFIFOOver | TxOK | TxErr; + RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); @@ -416,6 +419,53 @@ static int mdio_read(void *ioaddr, int R return value; } +static unsigned int rtl8169_tbi_reset_pending(void *ioaddr) +{ + return RTL_R32(TBICSR) & TBIReset; +} + +static unsigned int rtl8169_xmii_reset_pending(void *ioaddr) +{ + return mdio_read(ioaddr, 0) & 0x8000; +} + +static unsigned int rtl8169_tbi_link_ok(void *ioaddr) +{ + return RTL_R32(TBICSR) & TBILinkOk; +} + +static unsigned int rtl8169_xmii_link_ok(void *ioaddr) +{ + return RTL_R8(PHYstatus) & LinkStatus; +} + +static void rtl8169_tbi_reset_enable(void *ioaddr) +{ + RTL_W32(TBICSR, RTL_R32(TBICSR) | TBIReset); +} + +static void rtl8169_xmii_reset_enable(void *ioaddr) +{ + unsigned int val; + + val = (mdio_read(ioaddr, PHY_CTRL_REG) | 0x8000) & 0xffff; + mdio_write(ioaddr, PHY_CTRL_REG, val); +} + +static void rtl8169_check_link_status(struct net_device *dev, + struct rtl8169_private *tp, void *ioaddr) +{ + unsigned long flags; + + spin_lock_irqsave(&tp->lock, flags); + if (tp->link_ok(ioaddr)) { + netif_carrier_on(dev); + printk(KERN_INFO PFX "%s: link up\n", dev->name); + } else + netif_carrier_off(dev); + spin_unlock_irqrestore(&tp->lock, flags); +} + static void rtl8169_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { @@ -493,8 +543,14 @@ static int rtl8169_set_speed(struct net_ u8 autoneg, u16 speed, u8 duplex) { struct rtl8169_private *tp = netdev_priv(dev); + int ret; + + ret = tp->set_speed(dev, autoneg, speed, duplex); + + if (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full) + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); - return tp->set_speed(dev, autoneg, speed, duplex); + return ret; } static int rtl8169_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) @@ -753,56 +809,42 @@ static void rtl8169_hw_phy_config(struct mdio_write(ioaddr, 31, 0x0000); //w 31 2 0 0 } -static void rtl8169_hw_phy_reset(struct net_device *dev) -{ - struct rtl8169_private *tp = netdev_priv(dev); - void *ioaddr = tp->mmio_addr; - int i, val; - - printk(KERN_WARNING PFX "%s: Reset RTL8169s PHY\n", dev->name); - - val = (mdio_read(ioaddr, 0) | 0x8000) & 0xffff; - mdio_write(ioaddr, 0, val); - - for (i = 50; i >= 0; i--) { - if (!(mdio_read(ioaddr, 0) & 0x8000)) - break; - udelay(100); /* Gross */ - } - - if (i < 0) { - printk(KERN_WARNING PFX "%s: no PHY Reset ack. Giving up.\n", - dev->name); - } -} - static void rtl8169_phy_timer(unsigned long __opaque) { struct net_device *dev = (struct net_device *)__opaque; struct rtl8169_private *tp = netdev_priv(dev); struct timer_list *timer = &tp->timer; void *ioaddr = tp->mmio_addr; + unsigned long timeout = RTL8169_PHY_TIMEOUT; assert(tp->mac_version > RTL_GIGA_MAC_VER_B); assert(tp->phy_version < RTL_GIGA_PHY_VER_G); - if (RTL_R8(PHYstatus) & LinkStatus) - tp->phy_link_down_cnt = 0; - else { - tp->phy_link_down_cnt++; - if (tp->phy_link_down_cnt >= 12) { - int reg; - - // If link on 1000, perform phy reset. - reg = mdio_read(ioaddr, PHY_1000_CTRL_REG); - if (reg & PHY_Cap_1000_Full) - rtl8169_hw_phy_reset(dev); + if (!(tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) + return; - tp->phy_link_down_cnt = 0; - } + spin_lock_irq(&tp->lock); + + if (tp->phy_reset_pending(ioaddr)) { + /* + * A busy loop could burn quite a few cycles on nowadays CPU. + * Let's delay the execution of the timer for a few ticks. + */ + timeout = HZ/10; + goto out_mod_timer; } - mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); + 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: + mod_timer(timer, jiffies + timeout); +out_unlock: + spin_unlock_irq(&tp->lock); } static inline void rtl8169_delete_timer(struct net_device *dev) @@ -815,8 +857,6 @@ static inline void rtl8169_delete_timer( return; del_timer_sync(timer); - - tp->phy_link_down_cnt = 0; } static inline void rtl8169_request_timer(struct net_device *dev) @@ -828,8 +868,6 @@ static inline void rtl8169_request_timer (tp->phy_version >= RTL_GIGA_PHY_VER_G)) return; - tp->phy_link_down_cnt = 0; - init_timer(timer); timer->expires = jiffies + RTL8169_PHY_TIMEOUT; timer->data = (unsigned long)(dev); @@ -1014,11 +1052,17 @@ rtl8169_init_one(struct pci_dev *pdev, c if (RTL_R8(PHYstatus) & TBI_Enable) { tp->set_speed = rtl8169_set_speed_tbi; tp->get_settings = rtl8169_gset_tbi; + tp->phy_reset_enable = rtl8169_tbi_reset_enable; + tp->phy_reset_pending = rtl8169_tbi_reset_pending; + tp->link_ok = rtl8169_tbi_link_ok; tp->phy_1000_ctrl_reg = PHY_Cap_1000_Full; /* Implied by TBI */ } else { tp->set_speed = rtl8169_set_speed_xmii; tp->get_settings = rtl8169_gset_xmii; + tp->phy_reset_enable = rtl8169_xmii_reset_enable; + tp->phy_reset_pending = rtl8169_xmii_reset_pending; + tp->link_ok = rtl8169_xmii_link_ok; } // Get MAC address. FIXME: read EEPROM @@ -1752,10 +1796,7 @@ rtl8169_interrupt(int irq, void *dev_ins break; handled = 1; -/* - if (status & LinkChg) - link_changed = RTL_R16 (CSCR) & CSCR_LinkChangeBit; -*/ + status &= tp->intr_mask; RTL_W16(IntrStatus, (status & RxFIFOOver) ? (status | RxOverflow) : status); @@ -1763,6 +1804,9 @@ rtl8169_interrupt(int irq, void *dev_ins if (!(status & rtl8169_intr_mask)) break; + if (status & LinkChg) + rtl8169_check_link_status(dev, tp, ioaddr); + #ifdef CONFIG_R8169_NAPI RTL_W16(IntrMask, rtl8169_intr_mask & ~rtl8169_napi_event); tp->intr_mask = ~rtl8169_napi_event; @@ -1776,7 +1820,7 @@ rtl8169_interrupt(int irq, void *dev_ins break; #else // Rx interrupt - if (status & (RxOK | LinkChg | RxOverflow | RxFIFOOver)) { + if (status & (RxOK | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); } // Tx interrupt _ From romieu@fr.zoreil.com Wed Jun 2 16:33:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 16:33:39 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52NXWgi014142 for ; Wed, 2 Jun 2004 16:33:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i52NXJuX022291; Thu, 3 Jun 2004 01:33:19 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i52NXJ76022290; Thu, 3 Jun 2004 01:33:19 +0200 Date: Thu, 3 Jun 2004 01:33:19 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, luto@myrealbox.com, netdev@oss.sgi.com Subject: [patch 2.6.7-rc2 + bk-netdev 2/4] r8169: initial link setup rework Message-ID: <20040603013319.A22272@electric-eye.fr.zoreil.com> References: <200406010922.i519MIr27814@mail.osdl.org> <40BE2FAB.1040008@pobox.com> <20040603013128.D18059@electric-eye.fr.zoreil.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: <20040603013128.D18059@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Thu, Jun 03, 2004 at 01:31:28AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 5569 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: 5919 Lines: 193 Use rtl8169_set_speed() for link setup in rtl8169_init_one(): - the code which handles the option checking is isolated; - display (once) a notice message about the deprecated interface; - rtl8169_open() enables the phy timer if the link is not up; - rtl8169_set_speed() checks that the netdevice is actually ready in order to activate the timer. diff -puN drivers/net/r8169.c~r8169-link-10 drivers/net/r8169.c --- linux-2.6.7-rc2/drivers/net/r8169.c~r8169-link-10 2004-06-02 23:18:02.000000000 +0200 +++ linux-2.6.7-rc2-fr/drivers/net/r8169.c 2004-06-02 23:18:02.000000000 +0200 @@ -7,7 +7,7 @@ Feb 4 2002 - created initially by ShuChen . May 20 2002 - Add link status force-mode and TBI mode support. ========================================================================= - 1. The media can be forced in 5 modes. + 1. [DEPRECATED: use ethtool instead] The media can be forced in 5 modes. Command: 'insmod r8169 media = SET_MEDIA' Ex: 'insmod r8169 media = 0x04' will force PHY to operate in 100Mpbs Half-duplex. @@ -466,6 +466,38 @@ static void rtl8169_check_link_status(st spin_unlock_irqrestore(&tp->lock, flags); } +static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) +{ + struct { + u16 speed; + u8 duplex; + u8 autoneg; + u8 media; + } link_settings[] = { + { SPEED_10, DUPLEX_HALF, AUTONEG_DISABLE, _10_Half }, + { SPEED_10, DUPLEX_FULL, AUTONEG_DISABLE, _10_Full }, + { SPEED_100, DUPLEX_HALF, AUTONEG_DISABLE, _100_Half }, + { SPEED_100, DUPLEX_FULL, AUTONEG_DISABLE, _100_Full }, + { SPEED_1000, DUPLEX_FULL, AUTONEG_DISABLE, _1000_Full }, + /* Make TBI happy */ + { SPEED_1000, DUPLEX_FULL, AUTONEG_ENABLE, 0xff } + }, *p; + unsigned char option; + + option = ((idx < MAX_UNITS) && (idx >= 0)) ? media[idx] : 0xff; + + if ((option != 0xff) && !idx) + printk(KERN_WARNING PFX "media option is deprecated.\n"); + + for (p = link_settings; p->media != 0xff; p++) { + if (p->media == option) + break; + } + *autoneg = p->autoneg; + *speed = p->speed; + *duplex = p->duplex; +} + static void rtl8169_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { @@ -547,7 +579,7 @@ static int rtl8169_set_speed(struct net_ ret = tp->set_speed(dev, autoneg, speed, duplex); - if (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full) + if (netif_running(dev) && (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); return ret; @@ -1027,8 +1059,9 @@ rtl8169_init_one(struct pci_dev *pdev, c void *ioaddr = NULL; static int board_idx = -1; static int printed_version = 0; + u8 autoneg, duplex; + u16 speed; int i, rc; - int option = -1, Cap10_100 = 0, Cap1000 = 0; assert(pdev != NULL); assert(ent != NULL); @@ -1131,97 +1164,12 @@ rtl8169_init_one(struct pci_dev *pdev, c mdio_write(ioaddr, 0x0b, 0x0000); //w 0x0b 15 0 0 } - // if TBI is not endbled - if (!(RTL_R8(PHYstatus) & TBI_Enable)) { - int val = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); - - option = (board_idx >= MAX_UNITS) ? 0 : media[board_idx]; - // Force RTL8169 in 10/100/1000 Full/Half mode. - if (option > 0) { - printk(KERN_INFO "%s: Force-mode Enabled.\n", - dev->name); - Cap10_100 = 0, Cap1000 = 0; - switch (option) { - case _10_Half: - Cap10_100 = PHY_Cap_10_Half_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _10_Full: - Cap10_100 = PHY_Cap_10_Full_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _100_Half: - Cap10_100 = PHY_Cap_100_Half_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _100_Full: - Cap10_100 = PHY_Cap_100_Full_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _1000_Full: - Cap10_100 = PHY_Cap_100_Full_Or_Less; - Cap1000 = PHY_Cap_1000_Full; - break; - default: - break; - } - // leave PHY_AUTO_NEGO_REG bit4:0 unchanged - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, - Cap10_100 | (val & 0x1F)); - mdio_write(ioaddr, PHY_1000_CTRL_REG, Cap1000); - } else { - printk(KERN_INFO "%s: Auto-negotiation Enabled.\n", - dev->name); + rtl8169_link_option(board_idx, &autoneg, &speed, &duplex); - // enable 10/100 Full/Half Mode - // leave PHY_AUTO_NEGO_REG bit4:0 unchanged - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, - PHY_Cap_100_Full_Or_Less | (val & 0x1f)); - - // enable 1000 Full Mode - mdio_write(ioaddr, PHY_1000_CTRL_REG, - PHY_Cap_1000_Full); - - } - - // Enable auto-negotiation and restart auto-nigotiation - mdio_write(ioaddr, PHY_CTRL_REG, - PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); - udelay(100); - - // wait for auto-negotiation process - for (i = 10000; i > 0; i--) { - //check if auto-negotiation complete - if (mdio_read(ioaddr, PHY_STAT_REG) & - PHY_Auto_Neco_Comp) { - udelay(100); - option = RTL_R8(PHYstatus); - if (option & _1000bpsF) { - printk(KERN_INFO - "%s: 1000Mbps Full-duplex operation.\n", - dev->name); - } else { - printk(KERN_INFO - "%s: %sMbps %s-duplex operation.\n", - dev->name, - (option & _100bps) ? "100" : - "10", - (option & FullDup) ? "Full" : - "Half"); - } - break; - } else { - udelay(100); - } - } // end for-loop to wait for auto-negotiation process - - } else { - udelay(100); - printk(KERN_INFO - "%s: 1000Mbps Full-duplex operation, TBI Link %s!\n", - dev->name, - (RTL_R32(TBICSR) & TBILinkOK) ? "OK" : "Failed"); - } + rtl8169_set_speed(dev, autoneg, speed, duplex); + + if (RTL_R8(PHYstatus) & TBI_Enable) + printk(KERN_INFO PFX "%s: TBI auto-negotiating\n", dev->name); return 0; } @@ -1322,6 +1270,8 @@ rtl8169_open(struct net_device *dev) rtl8169_hw_start(dev); rtl8169_request_timer(dev); + + rtl8169_check_link_status(dev, tp, tp->mmio_addr); out: return retval; _ From romieu@fr.zoreil.com Wed Jun 2 16:37:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 16:37:36 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52NbWgi014813 for ; Wed, 2 Jun 2004 16:37:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i52NZBuX022375; Thu, 3 Jun 2004 01:35:11 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i52NZBcA022374; Thu, 3 Jun 2004 01:35:11 +0200 Date: Thu, 3 Jun 2004 01:35:11 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, luto@myrealbox.com, netdev@oss.sgi.com Subject: [patch 2.6.7-rc2 + bk-netdev 3/4] r8169: gcc bug workaround Message-ID: <20040603013511.B22272@electric-eye.fr.zoreil.com> References: <200406010922.i519MIr27814@mail.osdl.org> <40BE2FAB.1040008@pobox.com> <20040603013128.D18059@electric-eye.fr.zoreil.com> <20040603013319.A22272@electric-eye.fr.zoreil.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: <20040603013319.A22272@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Thu, Jun 03, 2004 at 01:33:19AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 5572 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: 1061 Lines: 29 Add a temporary variable to workaround gcc 2.95.3 bug. diff -puN drivers/net/r8169.c~r8169-gcc-killed-me drivers/net/r8169.c --- linux-2.6.7-rc2/drivers/net/r8169.c~r8169-gcc-killed-me 2004-06-03 00:15:34.000000000 +0200 +++ linux-2.6.7-rc2-fr/drivers/net/r8169.c 2004-06-03 00:15:34.000000000 +0200 @@ -1542,6 +1542,7 @@ rtl8169_start_xmit(struct sk_buff *skb, if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { dma_addr_t mapping; + u32 status; mapping = pci_map_single(tp->pci_dev, skb->data, len, PCI_DMA_TODEVICE); @@ -1549,8 +1550,10 @@ rtl8169_start_xmit(struct sk_buff *skb, tp->Tx_skbuff[entry] = skb; tp->TxDescArray[entry].addr = cpu_to_le64(mapping); - tp->TxDescArray[entry].status = cpu_to_le32(OWNbit | FSbit | - LSbit | len | (EORbit * !((entry + 1) % NUM_TX_DESC))); + /* anti gcc 2.95.3 bugware */ + status = OWNbit | FSbit | LSbit | len | + (EORbit * !((entry + 1) % NUM_TX_DESC)); + tp->TxDescArray[entry].status = cpu_to_le32(status); RTL_W8(TxPoll, 0x40); //set polling bit _ From romieu@fr.zoreil.com Wed Jun 2 16:37:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 16:37:35 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i52NbWgi014814 for ; Wed, 2 Jun 2004 16:37:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i52NaauX022398; Thu, 3 Jun 2004 01:36:36 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i52NaaTu022397; Thu, 3 Jun 2004 01:36:36 +0200 Date: Thu, 3 Jun 2004 01:36:36 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, luto@myrealbox.com, netdev@oss.sgi.com Subject: [patch 2.6.7-rc2 + bk-netdev 4/4] r8169: tx lock removal Message-ID: <20040603013636.C22272@electric-eye.fr.zoreil.com> References: <200406010922.i519MIr27814@mail.osdl.org> <40BE2FAB.1040008@pobox.com> <20040603013128.D18059@electric-eye.fr.zoreil.com> <20040603013319.A22272@electric-eye.fr.zoreil.com> <20040603013511.B22272@electric-eye.fr.zoreil.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: <20040603013511.B22272@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Thu, Jun 03, 2004 at 01:35:11AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 5571 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: 1779 Lines: 73 spinlock removal crusade. The patch rephrases the spinlock_irq() in rtl8169_start_xmit() and its companion in the Tx irq handling patch in terms of ordered operations. diff -puN drivers/net/r8169.c~r8169-tx-lock-removal drivers/net/r8169.c --- linux-2.6.7-rc2/drivers/net/r8169.c~r8169-tx-lock-removal 2004-06-03 00:15:37.000000000 +0200 +++ linux-2.6.7-rc2-fr/drivers/net/r8169.c 2004-06-03 00:15:37.000000000 +0200 @@ -1538,8 +1538,6 @@ rtl8169_start_xmit(struct sk_buff *skb, len = ETH_ZLEN; } - spin_lock_irq(&tp->lock); - if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { dma_addr_t mapping; u32 status; @@ -1560,16 +1558,20 @@ rtl8169_start_xmit(struct sk_buff *skb, dev->trans_start = jiffies; tp->cur_tx++; + smp_wmb(); } else goto err_drop; - if ((tp->cur_tx - NUM_TX_DESC) == tp->dirty_tx) { + u32 dirty = tp->dirty_tx; + netif_stop_queue(dev); + smp_rmb(); + if (dirty != tp->dirty_tx) + netif_wake_queue(dev); } -out: - spin_unlock_irq(&tp->lock); +out: return 0; err_drop: @@ -1590,6 +1592,7 @@ rtl8169_tx_interrupt(struct net_device * assert(ioaddr != NULL); dirty_tx = tp->dirty_tx; + smp_rmb(); tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { @@ -1616,6 +1619,7 @@ rtl8169_tx_interrupt(struct net_device * if (tp->dirty_tx != dirty_tx) { tp->dirty_tx = dirty_tx; + smp_wmb(); if (netif_queue_stopped(dev)) netif_wake_queue(dev); } @@ -1777,11 +1781,8 @@ rtl8169_interrupt(int irq, void *dev_ins rtl8169_rx_interrupt(dev, tp, ioaddr); } // Tx interrupt - if (status & (TxOK | TxErr)) { - spin_lock(&tp->lock); + if (status & (TxOK | TxErr)) rtl8169_tx_interrupt(dev, tp, ioaddr); - spin_unlock(&tp->lock); - } #endif boguscnt--; _ From jm@jm.kir.nu Wed Jun 2 18:41:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 18:41:28 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i531fOgi019142 for ; Wed, 2 Jun 2004 18:41:25 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BVhD6-00023L-Bx; Wed, 02 Jun 2004 18:40:00 -0700 Date: Wed, 2 Jun 2004 18:40:00 -0700 From: Jouni Malinen To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040603014000.GA7548@jm.kir.nu> Mail-Followup-To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <20040602155542.GC24822@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602155542.GC24822@ruslug.rutgers.edu> User-Agent: Mutt/1.5.6i X-archive-position: 5573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 1307 Lines: 27 On Wed, Jun 02, 2004 at 11:55:42AM -0400, Luis R. Rodriguez wrote: > If you find the patches that'd be great :). I'll see what I can do about > fixing up extended MLME. I'll keep you posted. I now know where the wpa_supplicant part is and once I find the matching patch for Prism54 driver, I'll send them both to you. > I have yet to review most of the wpa_supplicant code so I cannot say for > sure yet what I think should go into the kernel. I e-mailed most lists > mainly to get comments from others who have poked at wpa_supplicant > and/or are looking into adding WPA client support into their drivers. > I just wanted to make sure we were heading in the right direction since > I only see 2 drivers that are currently using wpa_supplicant. You may have seen only two drivers, but actually I'm already aware of at least seven drivers that work with wpa_supplicant.. All of these are not yet available publicly, though. I believe that the current design for wpa_supplicant is quite alright for most cases. I would like to give some more thought for the roaming part (i.e., consider giving more control for the driver), but this should be doable in a backward compatible way without breaking support with existing code. -- Jouni Malinen PGP id EFC895FA From ramalhais@serrado.net Wed Jun 2 19:38:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 19:38:26 -0700 (PDT) Received: from smtp.netcabo.pt (smtp.netcabo.pt [212.113.174.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i532cMgi020547 for ; Wed, 2 Jun 2004 19:38:23 -0700 Received: from mail.serrado.net ([81.84.124.62]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Jun 2004 03:38:12 +0100 Received: (qmail 15554 invoked from network); 3 Jun 2004 02:38:10 -0000 Received: from rootix-w.resnet.serrado.net ([192.168.1.77]) (envelope-sender ) by mail.serrado.net (qmail-ldap-1.03) with SMTP for ; 3 Jun 2004 02:38:10 -0000 Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support From: Pedro Ramalhais To: Jouni Malinen Cc: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel In-Reply-To: <20040603014000.GA7548@jm.kir.nu> References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <20040602155542.GC24822@ruslug.rutgers.edu> <20040603014000.GA7548@jm.kir.nu> Content-Type: text/plain Message-Id: <1086230284.7604.38.camel@rootix> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 03 Jun 2004 03:38:05 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 02:38:12.0933 (UTC) FILETIME=[D0CA1F50:01C44913] X-archive-position: 5574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ramalhais@serrado.net Precedence: bulk X-list: netdev Content-Length: 3771 Lines: 70 Pre-Scriptum: Please excuse me for cross posting and/or if this mail is not relevant for the recipient mailing list/people. Hi Jouni (and other interest wireless driver developers)! As you may know (or not), the ipw2100 driver is somewhat based on hostap code. We use some code from hostap in the ipw2100 driver, and use the hostap driver externally as a way to provide WEP. I'm currently working on turning hostap_crypt* into ieee80211_crypt* in such a way that could be used in a generic way by all drivers that need host based WEP (and TKIP/CCMP). I basically renamed the hostap_crypt* to ieee80211_crypt* and search&replaced hostap with ieee80211. Also made hostap_crypt.c into a module (instead of having to rely on hostap.o). I have WEP working and a Makefile that can be used in the kernel or externally. I took a look at the TKIP and CCMP source files and it is somewhat tied up to ioctls and headers (just took a quick look correct me if i'm wrong) from hostap. This makes it somewhat difficult to turn them into code that compiles without hostap code. Besides this, the ipw2100 code also has an attempt at a somewhat generic ieee80211 interface for drivers. ieee80211_rx.c is mostly based on hostap_hw.c code (which looks like is now in CVS as hostap_80211_rx.c ) and there's also ieee80211_tx.c which i think was created from scratch by James Ketrenos (ipw2100 main developer @intel). My question is: would it be interesting to try and merge code from hostap, ipw2100 and possibly other drivers to try to create generic code for 80211 and 80211_crypt? How much interest is there on the part of the developers (hostap, prism54, atmel, etc...). I'm asking this because AFAICS, the hostap driver always had an history of more focus on new features, functionality, bug fixes, than "standard" APIs, etc... and i completely understand that and thank god it has been like this because the final result was a really nice driver. Would you accept patches at least for now to make hostap_crypt* into ieee80211_crypt*? Sorry, i have so many questions and ideas, that i cannot express myself very well =:-). This is getting lengthy, so, hope you got the idea at least of some of my questions/ideas/worries, etc.... Thank you! PS: Comments, ideas, proposals, etc are welcome for discussion.(What is the best way to discuss this matter? There's a large number of developers involved. Maybe netdev?) On Thu, 2004-06-03 at 02:40, Jouni Malinen wrote: > On Wed, Jun 02, 2004 at 11:55:42AM -0400, Luis R. Rodriguez wrote: > > > If you find the patches that'd be great :). I'll see what I can do about > > fixing up extended MLME. I'll keep you posted. > > I now know where the wpa_supplicant part is and once I find the matching > patch for Prism54 driver, I'll send them both to you. > > > I have yet to review most of the wpa_supplicant code so I cannot say for > > sure yet what I think should go into the kernel. I e-mailed most lists > > mainly to get comments from others who have poked at wpa_supplicant > > and/or are looking into adding WPA client support into their drivers. > > I just wanted to make sure we were heading in the right direction since > > I only see 2 drivers that are currently using wpa_supplicant. > > You may have seen only two drivers, but actually I'm already aware of at > least seven drivers that work with wpa_supplicant.. All of these are not > yet available publicly, though. > > I believe that the current design for wpa_supplicant is quite alright > for most cases. I would like to give some more thought for the roaming > part (i.e., consider giving more control for the driver), but this > should be doable in a backward compatible way without breaking support > with existing code. -- Pedro Ramalhais From jgarzik@pobox.com Wed Jun 2 20:45:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 20:45:49 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i533jhgi025220 for ; Wed, 2 Jun 2004 20:45:43 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVjAj-0000DF-TH; Thu, 03 Jun 2004 04:45:42 +0100 Message-ID: <40BE9ED8.9020505@pobox.com> Date: Wed, 02 Jun 2004 23:45:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , jkmaline@cc.hut.fi, James P Ketrenos Subject: wireless-2.6 queue opened Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5575 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: 2761 Lines: 62 It's high time that Linux get a serious effort going on a generic 802.11 stack, as it seems we are in danger of having every new wireless driver invent one if we do not. Given that there are at least 3 complete wireless stacks (or thereabouts) floating about for Linux, I picked one that I felt had the best chance of being _evolved_ into a nice, clean, generic wireless stack: HostAP. My general hope (plan?) is that generic wireless code can be arrived at without horribly intrusive changes that require a 2.7 kernel. wireless-2.6 is targetted for eventual merging, but it won't be submitted anytime soon. Now it's time for open source to kick into action :) wireless-2.6 queue is available in patch form or BitKeeper for review. Or, if you object to my selection of wireless code, now's the time to speak up. BTW to Intel Centrino folks -- I would like to merge the current (open source) Centrino driver into wireless-2.6 as well, to get it more exposure, and also to ensure that it uses whatever generic 802.11 code happens to appear... Oh, and please speak up on netdev@oss.sgi.com, or at least CC there. Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.7-rc2-bk3-wireless1.patch.bz2 BitKeeper (all of these are equivalent): bk://kernel.bkbits.net/jgarzik/wireless-2.6 bk://gkernel.bkbits.net/wireless-2.6 http://gkernel.bkbits.net/wireless-2.6 (note: _not_ a Web URL) Finally, here is Jouni's patch submission message, elaborating on the driver-specific details: > Finally, here's the first attempt at submitting Host AP code for > wireless-2.6 tree. In addition, this could be considered for merging > into linus-2.5 tree, so review and comments are very much welcome. Host > AP code has lived in an external CVS repository for three years and is > widely used. > > The included patch has minimal changes to the current tree (against > 2.6.6, but should apply to different versions with some differences in > line numbers) for including a new directory drivers/net/wireless/hostap. > The contents of that new directory is a bit large for a patch file and > since all the files are new, I made it available as a compressed tarball > at http://hostap.epitest.fi/hostap-linux.tgz. This should be untarred in > the root of the kernel tree (i.e., the file paths in the tarball start > with drivers/net/wirelss/hostap/...). > > I removed most of the backwards (for Linux 2.4, pcmcia-cs modules, > different wireless extensions versions) compatibility code. In addition, > I replaced integrated implementations of ARC4, Michael MIC, and AES with > crypto API. AES-CCM mode is still implemented in hostap_crypt_ccmp.c, > but it could be moved at some point to crypto API as a new encryption > mode. From jm@jm.kir.nu Wed Jun 2 20:46:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 20:46:30 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i533kPgi025328 for ; Wed, 2 Jun 2004 20:46:25 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BVjA3-0002AP-Dk; Wed, 02 Jun 2004 20:44:59 -0700 Date: Wed, 2 Jun 2004 20:44:59 -0700 From: Jouni Malinen To: Pedro Ramalhais Cc: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040603034458.GD7548@jm.kir.nu> Mail-Followup-To: Pedro Ramalhais , Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Jean Tourrilhes , Linux Kernel References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <20040602155542.GC24822@ruslug.rutgers.edu> <20040603014000.GA7548@jm.kir.nu> <1086230284.7604.38.camel@rootix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086230284.7604.38.camel@rootix> User-Agent: Mutt/1.5.6i X-archive-position: 5576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 4459 Lines: 89 On Thu, Jun 03, 2004 at 03:38:05AM +0100, Pedro Ramalhais wrote: > As you may know (or not), the ipw2100 driver is somewhat based on hostap > code. We use some code from hostap in the ipw2100 driver, and use the > hostap driver externally as a way to provide WEP. > I'm currently working on turning hostap_crypt* into ieee80211_crypt* in > such a way that could be used in a generic way by all drivers that need > host based WEP (and TKIP/CCMP). I basically renamed the hostap_crypt* to > ieee80211_crypt* and search&replaced hostap with ieee80211. Also made > hostap_crypt.c into a module (instead of having to rely on hostap.o). I do not understand what kind of changes you think are required. Renaming the functions/structures is not really changing anything and hostap_crypt.o used to be a separate module (and it should still be possible to compile it as such by defining HOSTAP_CRYPT_MODULE when compiling the Host AP code). It sounds like your changes are just making it more difficult to maintain generic code because of making it require more work to merge changes back. With the changes to use crypto API, there's already couple of different versions of the crypto code for Host AP. I would rather not bring in more versions. The improvements should go to the wireless-2.6 tree. As far as I can tell, the version that I submitted couple of days ago for wireless-2.6 (and potentially linus-2.5) trees, should be usable as is from other drivers. Yes, hostap module will include some extra functionality that is not needed, but it does not make it any more difficult to use the encryption part which should be fully hardware independent. This can be easily (again) extracted, if it looks like this code will be used from multiple drivers. > I have WEP working and a Makefile that can be used in the kernel or > externally. I took a look at the TKIP and CCMP source files and it is > somewhat tied up to ioctls and headers (just took a quick look correct > me if i'm wrong) from hostap. This makes it somewhat difficult to turn > them into code that compiles without hostap code. Tied to ioctls?? There is no ioctl processing in the Host AP crypto code. The header files are mainly for defining the IEEE 802.11 header. In addition, Host AP code can already be used in the kernel and externally.. > Besides this, the ipw2100 code also has an attempt at a somewhat generic > ieee80211 interface for drivers. ieee80211_rx.c is mostly based on > hostap_hw.c code (which looks like is now in CVS as hostap_80211_rx.c ) > and there's also ieee80211_tx.c which i think was created from scratch > by James Ketrenos (ipw2100 main developer @intel). This sounds similar to what the current Host AP driver uses hostap_80211_{rx,tx}.c. > My question is: would it be interesting to try and merge code from > hostap, ipw2100 and possibly other drivers to try to create generic code > for 80211 and 80211_crypt? Yes and this is what has been discussed on netdev and (admittedly, slowly so far) started with wireless-2.6. > developers (hostap, prism54, atmel, etc...). I'm asking this because > AFAICS, the hostap driver always had an history of more focus on new > features, functionality, bug fixes, than "standard" APIs, etc... and i > completely understand that and thank god it has been like this because > the final result was a really nice driver. I believe that one needs to first experiment with the features/design before being able to design a standard API. There has already been quite many versions of Linux wireless extensions and I would rather first see what would be a common design that could work with most wireless cards and then design an API for this. For many functions, we are starting to have all the needed information to actually to this successfully. > Would you accept patches at least for now to make hostap_crypt* into > ieee80211_crypt*? Sure, if there is something that really improves the current situation in some way. I don't think that just renaming the functions would be very useful at that point. Of course it can be done, but I would prefer to see a bit more design on the other parts of the IEEE 802.11 support and its place in the Linux net stack. > PS: Comments, ideas, proposals, etc are welcome for discussion.(What is > the best way to discuss this matter? There's a large number of > developers involved. Maybe netdev?) netdev -- Jouni Malinen PGP id EFC895FA From jgarzik@pobox.com Wed Jun 2 21:06:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 21:06:53 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5346ogi026326 for ; Wed, 2 Jun 2004 21:06:51 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVjVA-0000OZ-Pm; Thu, 03 Jun 2004 05:06:48 +0100 Message-ID: <40BEA3CB.60908@pobox.com> Date: Thu, 03 Jun 2004 00:06:35 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: "Luis R. Rodriguez" , Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jean Tourrilhes , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> In-Reply-To: <20040602132313.GB7341@jm.kir.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5577 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: 1307 Lines: 32 Jouni Malinen wrote: > The first thing I would like to see is an addition to Linux wireless > extensions for WPA/WPA2 so that we can get rid of the private ioctls in > the drivers. Even though these can often be similar, it would be nice to > just write one driver interface code in wpa_supplicant and have it > working with all Linu drivers.. I hope to find some time to write a > proposal for this. One of the things that is nice about wireless-2.6 is that is affords the opportunity to totally rethink the wireless extensions. Although a lot of people would howl, since HostAP is essentially new code from the mainline kernel perspective, a new userland API (and new or updated tools) could come along with it. I have mentioned in the past (no offense Jean!) that I do not like the overly-generic wireless handler structure. It is less type-safe than is generally preferred in Linux, IMO. A low-level wireless driver should not implement ioctls, it should implement callbacks in some sort of 'struct wireless_operations' as is done in other kernel subsystems. ioctl details should be hidden from low-level drivers as much as possible, through type-safe interfaces. Strive to make both the wireless driver API and the wireless userland API easy to change and evolve over time. Jeff From davem@redhat.com Wed Jun 2 21:12:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 21:12:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i534CCgi026826 for ; Wed, 2 Jun 2004 21:12: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 i534C2i5019106; Thu, 3 Jun 2004 00:12: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 i534C2002353; Thu, 3 Jun 2004 00:12: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 i534BrVL027965; Thu, 3 Jun 2004 00:11:53 -0400 Date: Wed, 2 Jun 2004 21:10:38 -0700 From: "David S. Miller" To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, jkmaline@cc.hut.fi, james.p.ketrenos@intel.com Subject: Re: wireless-2.6 queue opened Message-Id: <20040602211038.287628ac.davem@redhat.com> In-Reply-To: <40BE9ED8.9020505@pobox.com> References: <40BE9ED8.9020505@pobox.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5578 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: 485 Lines: 11 On Wed, 02 Jun 2004 23:45:28 -0400 Jeff Garzik wrote: > Given that there are at least 3 complete wireless stacks (or > thereabouts) floating about for Linux, I picked one that I felt had the > best chance of being _evolved_ into a nice, clean, generic wireless > stack: HostAP. Even though I authored one of the "other" stacks, I'm totally fine with this choice. Mainly because I simply lack the time or resources to continue working on the stack I started. From davem@redhat.com Wed Jun 2 21:38:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 21:38:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i534c2gi027678 for ; Wed, 2 Jun 2004 21:38:02 -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 i534bxi5025457; Thu, 3 Jun 2004 00:37:59 -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 i534bx006838; Thu, 3 Jun 2004 00:37:59 -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 i534boOB032603; Thu, 3 Jun 2004 00:37:50 -0400 Date: Wed, 2 Jun 2004 21:36:34 -0700 From: "David S. Miller" To: jkmaline@cc.hut.fi Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: hostap crypto bugs Message-Id: <20040602213634.11ec61bf.davem@redhat.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5579 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: 314 Lines: 9 You cannot invoke virt_to_page() on addresses on the kernel stack, and that is what the various HostAP crypto modules are doing. This happens to work on some platforms, but it is going to explode on others. Allocate these little header scratch area blobs in the per-crypto-instance structs you kmalloc instead. From jm@jm.kir.nu Wed Jun 2 23:35:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 23:36:02 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i536Zwgi002991 for ; Wed, 2 Jun 2004 23:35:59 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BVlo9-000200-1j; Wed, 02 Jun 2004 23:34:33 -0700 Date: Wed, 2 Jun 2004 23:34:33 -0700 From: Jouni Malinen To: "David S. Miller" Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [PATCH wireless-2.6] Re: hostap crypto bugs Message-ID: <20040603063432.GA7600@jm.kir.nu> References: <20040602213634.11ec61bf.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602213634.11ec61bf.davem@redhat.com> User-Agent: Mutt/1.5.6i X-archive-position: 5580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 4846 Lines: 151 On Wed, Jun 02, 2004 at 09:36:34PM -0700, David S. Miller wrote: > You cannot invoke virt_to_page() on addresses on the kernel stack, > and that is what the various HostAP crypto modules are doing. > > This happens to work on some platforms, but it is going to explode > on others. Thanks! I have not updated my non-x86 platforms to 2.6 kernels, so I had not yet had a change to explode anything with this.. > Allocate these little header scratch area blobs in the per-crypto-instance > structs you kmalloc instead. This patch (for wireless-2.6) should do this. I used separate buffers for RX and TX because they could be in theory called concurrently. Better to get this first working, but it might be worthwhile to consider the memory use at some point. This version uses 112 bytes of additional scratch buffers per key for CCMP. diff -u wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_ccmp.c jm-wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_ccmp.c --- wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_ccmp.c 2004-06-02 23:16:06.430130552 -0700 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_ccmp.c 2004-06-02 22:51:28.000000000 -0700 @@ -59,6 +59,11 @@ int key_idx; struct crypto_tfm *tfm; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN], + tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN]; + u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN]; }; @@ -133,13 +138,14 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm, struct hostap_ieee80211_hdr *hdr, - u8 *pn, size_t dlen, u8 *b0, u8 *aad, u8 *auth, + u8 *pn, size_t dlen, u8 *b0, u8 *auth, u8 *s0) { u8 *pos, qc = 0; size_t aad_len; u16 fc; int a4_included, qc_included; + u8 aad[2 * AES_BLOCK_LEN]; fc = le16_to_cpu(hdr->frame_control); a4_included = ((fc & (WLAN_FC_TODS | WLAN_FC_FROMDS)) == @@ -211,8 +217,10 @@ int data_len, i, blocks, last, len; u8 *pos, *mic; struct hostap_ieee80211_hdr *hdr; - u8 aad[2 * AES_BLOCK_LEN], b0[AES_BLOCK_LEN], b[AES_BLOCK_LEN], - e[AES_BLOCK_LEN], s0[AES_BLOCK_LEN]; + u8 *b0 = key->tx_b0; + u8 *b = key->tx_b; + u8 *e = key->tx_e; + u8 *s0 = key->tx_s0; if (skb_headroom(skb) < CCMP_HDR_LEN || skb_tailroom(skb) < CCMP_MIC_LEN || @@ -243,7 +251,7 @@ *pos++ = key->tx_pn[0]; hdr = (struct hostap_ieee80211_hdr *) skb->data; - ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, aad, b, s0); + ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, b, s0); blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; last = data_len % AES_BLOCK_LEN; @@ -273,8 +281,9 @@ struct hostap_ccmp_data *key = priv; u8 keyidx, *pos; struct hostap_ieee80211_hdr *hdr; - u8 aad[2 * AES_BLOCK_LEN], b0[AES_BLOCK_LEN], b[AES_BLOCK_LEN], - a[AES_BLOCK_LEN]; + u8 *b0 = key->rx_b0; + u8 *b = key->rx_b; + u8 *a = key->rx_a; u8 pn[6]; int i, blocks, last, len; size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN - CCMP_MIC_LEN; @@ -331,7 +340,7 @@ return -4; } - ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, aad, a, b); + ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b); xor_block(mic, b, CCMP_MIC_LEN); blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; diff -u wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_tkip.c jm-wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_tkip.c --- wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_tkip.c 2004-06-02 23:16:06.441128880 -0700 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_crypt_tkip.c 2004-06-02 23:01:06.000000000 -0700 @@ -65,6 +65,9 @@ struct crypto_tfm *tfm_arc4; struct crypto_tfm *tfm_michael; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 rx_hdr[16], tx_hdr[16]; }; @@ -499,7 +502,6 @@ { struct hostap_tkip_data *tkey = priv; u8 *pos; - u8 hdr[16]; if (skb_tailroom(skb) < 8 || skb->len < hdr_len) { printk(KERN_DEBUG "Invalid packet for Michael MIC add " @@ -508,9 +510,9 @@ return -1; } - michael_mic_hdr(skb, hdr); + michael_mic_hdr(skb, tkey->tx_hdr); pos = skb_put(skb, 8); - if (michael_mic(tkey, &tkey->key[16], hdr, + if (michael_mic(tkey, &tkey->key[16], tkey->tx_hdr, skb->data + hdr_len, skb->len - 8 - hdr_len, pos)) return -1; @@ -539,14 +541,13 @@ int hdr_len, void *priv) { struct hostap_tkip_data *tkey = priv; - u8 hdr[16]; u8 mic[8]; if (!tkey->key_set) return -1; - michael_mic_hdr(skb, hdr); - if (michael_mic(tkey, &tkey->key[24], hdr, + michael_mic_hdr(skb, tkey->rx_hdr); + if (michael_mic(tkey, &tkey->key[24], tkey->rx_hdr, skb->data + hdr_len, skb->len - 8 - hdr_len, mic)) return -1; if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) { -- Jouni Malinen PGP id EFC895FA From jgarzik@pobox.com Wed Jun 2 23:50:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 23:50: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.12.10/8.12.9) with SMTP id i536oAgi003601 for ; Wed, 2 Jun 2004 23:50:11 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVm3F-0002QU-9n; Thu, 03 Jun 2004 07:50:09 +0100 Message-ID: <40BECA14.8020800@pobox.com> Date: Thu, 03 Jun 2004 02:49:56 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH wireless-2.6] Re: hostap crypto bugs References: <20040602213634.11ec61bf.davem@redhat.com> <20040603063432.GA7600@jm.kir.nu> In-Reply-To: <20040603063432.GA7600@jm.kir.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5581 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 applied From arthur@it.usyd.edu.au Wed Jun 2 23:52:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 23:52:18 -0700 (PDT) Received: from staff.cs.usyd.edu.au (staff.cs.usyd.edu.au [129.78.8.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i536qBgi003971 for ; Wed, 2 Jun 2004 23:52:12 -0700 Message-Id: <200406030652.i536qBgi003971@oss.sgi.com> Received: from staff.cs.usyd.edu.au. by staff.cs.usyd.edu.au.; Thu, 03 Jun 2004 16:52:03 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Thu, 03 Jun 2004 16:52:02 +1000 From: Arthur Scott To: netdev@oss.sgi.com Subject: Verify IQvlWvSs for REMOVETHISWORD netdev@oss.sgi.com X-Loop: arthur@it.usyd.edu.au X-archive-position: 5582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arthur@it.usyd.edu.au Precedence: bulk X-list: netdev Content-Length: 8857 Lines: 157 Hi! Your message has been received, but it hasn't been delivered to me yet. As I don't have any record of you sending me mail from this address before, I need to verify that you're not a spammer. Please reply and alter the Subject line to remove the word REMOVETHISWORD, and your previous message will be delivered, as will all your future messages. Thanks, and apologies for the inconvenience. Arthur Scott. Note: your original message is appended below. Please check it carefully. If it didn't originate from you, then a spammer is probably impersonating your address. In which case please ignore this message. ==== Original Message ==== Received: by staff.cs.usyd.edu.au with postie; Thu, 03 Jun 2004 16:51:54 +1000 Received: from 218.18.134.236 by staff.cs.usyd.edu.au.; Thu, 03 Jun 2004 16:51:40 +1000 X-Claimed-Received: from cs.su.oz.au From: netdev@oss.sgi.com To: arthur@cs.su.oz.au Subject: what do you think about it? Date: Thu, 3 Jun 2004 15:17:13 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_000046F7.00001905" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0004_000046F7.00001905 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit here is the next one! ------=_NextPart_000_0004_000046F7.00001905 Content-Type: application/x-zip-compressed; name="bill.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bill.zip" UEsDBAoAAAAAACY6wzBiZMYWCWMAAAljAAAMAAAAYmlsbC5ydGYuc2NyTVqQAAMAAAAEAAAA //8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuAAAAGsi X1YvQzEFL0MxBS9DMQWsXz8FI0MxBcdcOwU0QzEFL0MwBXBDMQWsS2wFIkMxBcdcOgUqQzEF l0U3BS5DMQVSaWNoL0MxBQAAAAAAAAAAQ29tcHJlc3NlZCBieSBQZXRpdGUgKGMpMTk5OSBJ YW4gTHVjay4AAFBFAABMAQMA7Kc7QAAAAAAAAAAA4AAPAQsBBgAAUAAAABwBAAAAAABCoAEA ABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAALABAAAEAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA/KEBAK8BAAAAkAEACAUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEA ABAAAABWAAAACAAAAAAAAAAAAAAAAAAAYAAA4C5wZXRpdGUAABAAAACQAQAIBQAAAF4AAAAA AAAAAAAAAAAAAEAAAEAAAAAAAAAAAKsDAAAAoAEAAAQAAAAEAAAAAAAAAAAAAAAAAABgAADi AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgCAACGAaK6i0QkBIPE Ko2QNAAAAIPECGoQi9hmBS0AUFJqAIsb/xNq//9TDEVSUk9SIQBDb3JydXB0IERhdGEhALgA oEEAaItwQABk/zUAAAAAZIklAAAAAGacYFBoAABAAIs8JIswZoHHgAeNdAYIiTiLXhBQVmoC aIAIAABXahNqBlZqBGiACAAAV//Tg+4IWfOlWWaDx2iBxsIAAADzpf/TWI2QuAEAAIsKD7rx H3MWiwQk/Yvwi/gDcgQDegjzpYPCDPzr4oPCEIta9IXbdNiLBCSLevgD+FKNNAHrF1hYWFp0 xOkc////AtJ1B4oWg+7/EtLDgfsAAAEAcw5oYMD//2hg/P//tgXrIoH7AAAEAHMOaICB//9o gPn//7YH6wxoAIP//2gA+///tghqADLSS6QzyYP7AH6k6Kr///9yF6QwX/9L6+1B6Jv///8T yeiU////cvLDM+3o6f///4PpA3MGiwQkQesji8EPts7odf///xPASXX2g/D/O0QkBIPVATtE JAiD1QCJBCToV////xPJ6FD///8TyXUI6Kb///+DwQIDzVYr2Y00OPOkXuuDLovAKRUAgKBk AAD8jwEAXDsBAAlOAAAAEAAA7wMAAD1qAQDgEwAAAGAAAEAYAACwdgEAvDUAAACAAACItAEA AAAAANEUAAAAAAAAAAAAAAAAAABiowEAiKIBAAAAAAAAAAAAAAAAAG2jAQCUogEAAAAAAAAA AAAAAAAAeqMBAKiiAQAAAAAAAAAAAAAAAACGowEAsKIBAAAAAAAAAAAAAAAAAJGjAQC4ogEA AAAAAAAAAAAAAAAAnqMBAMCiAQAAAAAAAAAAAAAAAAAAAAAAAAAAAMiiAQDWogEAAAAAAOKi AQDwogEAAKMBABKjAQAAAAAAJKMBAAAAAAALAACAAAAAAECjAQAAAAAAVKMBAAAAAAAAAE1l c3NhZ2VCb3hBAAAAd3NwcmludGZBAAAARXhpdFByb2Nlc3MAAABMb2FkTGlicmFyeUEAAAAA R2V0UHJvY0FkZHJlc3MAAAAAVmlydHVhbFByb3RlY3QAAAAASW50ZXJuZXRHZXRDb25uZWN0 ZWRTdGF0ZQAAAEdldE5ldHdvcmtQYXJhbXMAAAAAUmVnT3BlbktleUEAVVNFUjMyLmRsbABL RVJORUwzMi5kbGwAV0lOSU5FVC5kbGwAV1MyXzMyLmRsbABpcGhscGFwaS5kbGwAQURWQVBJ MzIuZGxsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVAIPrjUAIVVWKAH33zS/P MskPAHjI9oHdoJjwAKvEMWSx42D2AGgcyJDoa+7jG2uK1sjYDTIA3V+K09WSlJah4bgtkLEZ R6Low0+HAMHg4OB/MP6dLLDkyM+WWaGoL1esAKOqqdWdqROsFiZr1cpfFl3pv7rGAKxY6Z8Z jpcYAJDJy7d69HwIKfuH6caIgAt6u3tVPTsok7/0NHJZcQh3hdEW7ExqqjyNQcLjjXjLg9z+ sv8VcFcI6q1Qx0B9jcH2o/+Qsu4iOOgo9MlkAJdutn/Vbme/BmDcjpQQuqUAEHRKaimr4yoD Qx1WMkfnaQYfHG0f5lL9DQl8C7mEZwLEhfUcVAcAP8V2B2Z0vgH1F/+QzAcgQTSKeza0HpRt xmoQGFoUNZb1LQW4RZLwikbeWtALsQyco8oXYVGrIyiqZN1LHO1d7FKwAMVQRlr4wna5yW0k Iy8VS1dgJtzrbCIdf/+m5kVEYtKGBwx8LNTNSTRu8ItyJk+GGkydg5HUgD/ulDrhp25sIEnc /2+xU/+pVBJotlbJzVb/WWS2/3IKV3eGg8leN2KKOdlGRC06InS5KeSmnoAQR7hGfBa+hUVQ WKOi6hSNvpQFlcvtqv+YRaCmpmgogiOeVQoUuQ3QDRQKlm86jaCVslpessugpLsZ0pSmvP02 85lXz2AjQ1x48pJYsKTaCkzQI2FV/YaiaveK672nLQDN8FiHhpGUwxV6QrJAQHTSD3b8aqC6 i4akK3oaLJIC9VJQ94cOBWDlDOKlbSZYYt4rCxSV1JkdryiaWRdSjfEZRP3hQEQ5Ls4KKL7+ bLJ3DMHTNL1G91vkUXdQftSdoo3bq5+urfSR43bhxCMBWBRjO56N7Zc+W3bGnlVq6J2asa7D UJGn8tQGJcPw6OcdHbGQqmNYHC+vec+XH+gIzIT2S8TJiqv/GV/knxP0uy4/xikurc9yv2EH Ks1bpg82iOSn8KpNNV1bArNgJJwsnYALgFRF0pdJ9n+80gqCIP0OmlE5fYOmh2DhYu3TL9gI 2qoirHWv9iS0O9GIYXeXKICl99qazK9OFL/vwUoLA4hECbdBuJOPPv2wYrhQvSRzzCx3xTjr 6KtGWvaodMw4/bma76ZoDoT4hl2aiwns9KGrt9o1D499MOw5Yrg+fJAFyPHzh+PIohaZ4a3V ESS+/x2sFrFEXrE0w9iFJ63PqBWki82xxJxGKd27cjgBx1W4uDLgsXsg+Uqpk1evAk3pZGeZ ljShofB66+jhxFEKf4atdYUNg2u2WPA7fHezUDHlcDY5e15HaKmf0n1CqqG2VVLRRXEo3N2n UPnLwfwVy6CqFMBKaWfgcHsxY2Djqhkow83GsCqVQ2srXX7wssly3FAUkPZY5zakqqxX985S w+mK3luKA+VUpNy8ncgXMwVSWtXYRVxZW/cU8CgnvtPlZc02XYaXhLd6rUar54iF9ltbVmpD dQAUS/qljiCQnx9qZjEu3rIOaHhFwzQbLouzUN74T5VzEMg7Biv/fT/jv51fnOkv6JCXLOfh oDgjRfbUuT9ICceUswim8H56TVxmI27/ZqEhoHI9bsNNE3XJyb8fruNRMwySUHyYoR3Zv4R/ nGjDirH0JFREq94MXT61V2An716i0aJetUg30Ur8jjY2qTlQszfISFEncdN8/lW+8JGi8lHy aEYYR1LKmkZrbtGc86KIWXb4bLOBsNcmQDeQ9CAA/iF/96MFa817tBq4asVAc+GfaAipdI1r xcRY2lxTjK4tjqHklL0GksVzmMz6TTv3WthCHs0IyfMT9t35xDeHVaE9DR7vaUdm1/GQRR+W KNYA1/3oKo7KySgtzAdYCAGBQRD1zz1IVGnhzN8HceAPygko7gbC0oHFhg1GgFm1YL0PK2QX RYCPFY8Gou5TQtNErygQdINjc4kEA3YBEiNSumYLY7nxzc2vcS5aaoqRFTBDaZZUhLj9Ovzn vzNf0ZSS8CAxHePJSEIoGTJTSRxVKyj1ZHoKktYDAByLneizlzPRTf5OgWXEqHdiyEg7Nkod UBeInYfIMs6ZkwyV+3EjBcqLJy35q3MOTSllMDNARK//a6FeSX9haywFqVmPBg9454S7U4qh d02tswVOhJTdKh3rLCCVoZFirMm36m2g1EHzVokS9NBpqYyHOf5lR+W1EVRqF30RGqdjxkzg OZaEu4/Td4KcqQcULjZm94BMT5sW1whD6F1sqhBasgiHjf+Jb2Xtqai59hTlbvdXcUnJ3piU kP8qbIZ2/IS0Av25ymKmI3k6PKkpMGRehCnpJ3dkdTe6l6yupRA8sxkWCSm+8xeyP31KqisR UpqpcnBHypbvRWNAxYxCsNiQi8VoxYu3XStxo2q4CK39J8ksTFW/qPqm7IK/Be8VrjUCcsDE Qyl/vmxEnVQMmulQSAolYHeRcv7CGAt5AvrfJXUEvQgOKfuDeYQK9oQYGvxhmrPoJhKZECvD iyDfeaMaj108lICPCynBBifAM88CU8y0Yfde5B+4CPlP11m26lchekOJQ7oNqqrvAE6nw6nk 2NjAey78UqsJ+O6v3W9tfswv8UqIaj/8+u5lwmtZfrdcbpKlK3qEt4t2DrKhxEGsrqz6naiK wGmxQ8DihByg28sL6hUuFkf9VMzlBvSemJxixE8FJg2I7nR2KooA+HsV9TQW9zMFH/TkOG71 jIroYnUHAGqw4aHEV4zamtVJ2yTTyJbhBS7Gcf8XqL9X5JDGuTz1oJBSjjov2iQYRS7kp8yI nZfg3YKOQAc57ccdJ1QbjJBZCIie9UST8iGYdtkAhRTNA8YZGAjzLkT4IyL9IBHyLQiHWoSE Qlch8WwQ7nGI63ZE0EsixVh3pKY2iUasq8K6Ssar2pPOM314OvtdOpjpRQdJ6y8RPFWighCZ 3SkDvDgt3oWMrtCEyMu/KXSIyLuHMH0K+gMG06gV7zV+Us8GmDr9Vl86z0XLxBBmx8eaVSMS scEkdwRwBHMAjIII/mPazIDNhTG5BHdP1U8BUgBdDdU89ZIgRtI1X7dYKVYar3uqd+sVB7Sy SgDAca1xpA+d0e/6kV4sXeUgziejBCECZ5zhHmDAiVIhKGEgRo5vrPWB48Lg6AzsAL9C/k0s zhYX7SAFIco3m7z2Ip4BpK5kGOGYB2KrGMtAzbbfQ4AvMi7v0q7VxkU/u0WbojDQvtdKqlmJ CmCQrBSkDCXdQqYtGKrff8UYGFIAZnNhN0Xq0pIE+FByzY5HjkkXsrMl8EBo5kwoggOW/cDR C6TLvM+212tcjCovdjYzuqb3C/4aQriteXGN4fcY1/LKM6vemccFyLVppC3QgXYb/KuQkasL AkcQXlJBel4ScNNAG4IBRUM4AQl2C437ycDGYIovdlHppD30NpIZ12dkWNcjaA7wYCX+zHEQ 0K3UlzM+JbH/st8g87bFyCl4F7RCgOnE/G0AV1w6gJXCv15cNj6tpVr5kQUcb7GwlXdVLwsa PMzj/r5tDpjZBbitiN/UaLUvVS0D/l3+QWM7x0wrMNRPiwsOg5t9RSpzarMaQ79mSjCdUOau BSUsRbIhoCB17cGyGMXJrCFxMkpEBsw4cc505YemZ9WJUe0cMmPvTV7Zs/WsB3e9QKv83m+2 V6JXOE7ytGI654VX+94wHbHcPtcY98+vDK5MKwnv5HKJM0SRADji5P+bb7PTNZauQUl+Vd/J CMu6mnQ+QUeCqit3z9hkhL51PGkM2JMUenRSVPhc85UZexN64P8r3GKmHRTVWRTJk9h7ew0K SXzp5LvHuPW1RRDNBOC6autfe1qIGbnrbffEU8lTtRek1h2NASLbThmZRcVFLZ+pGQSHXe0u 38m/jFFTvrdLtoTXLSXeN15wHoE0gUr+OaBMt/6MVp3ixha+hZy8zVrlYiG+uWcf1RQiTwLQ CyBXtoYVsMiCOzSUeUetUdwhCVGfbNUeoDIFAdPB5qR6iEZ1LHyehyEL1eAOA2Jj9C+SRJAG OsKSr1WorJa01ajFExAiOCMoRAtCClrZtX0KShDSEsAVt38aH4Z4/2lEDuyfQvNAwUkNpyD7 oYyrzRGz90gCYCzpyIqMNaDAiKQvWGfjeQ24X83pRfuispcsu/J5kIIhfBAGDco8bfHkFjq2 xDSJ+QeeFWlpFVSbnSveB31Hwilh+kJQom6VGJSnCf4RqhdDoLusZByB8QniUoTuh4gieyFC s/6XJfnduh6Z3Mgh+tYzdJCIH3X4q4fo4fqMJConf1JDtRg8SYLI5TlyqkKPFZCh6sKSFMtI udF3GHzWUYnmWgqVCXHN00T7PiqVoapUa7x/pYHZiigXdnMREsGJUyMpBn1n9VzYXxKlzMkN e30KXiis16JtAcT2PE6l5g0Nan0zPxxFqU0ZUoOZakOO0qqvwBvIESsFsvb4YLVEGLKCiK53 jKCqnJi914pzMK8eQmlRGCJ3ahWmTyJc [TRUNCATED] From jgarzik@pobox.com Wed Jun 2 23:54:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jun 2004 23:54: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.12.10/8.12.9) with SMTP id i536s0gi004360 for ; Wed, 2 Jun 2004 23:54:01 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVm6y-0002Sj-5D for netdev@oss.sgi.com; Thu, 03 Jun 2004 07:54:00 +0100 Message-ID: <40BECAFC.7040405@pobox.com> Date: Thu, 03 Jun 2004 02:53:48 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Additional 802.11 net stack code posted Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5583 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: 469 Lines: 12 One of things that a proper "802.11 stack" should be is tie closely into the core net stack, so that translation to/from 802.3 isn't going on all the time. One wants to create, receive, and "understand" native 802.11 frames, and provide a sane management infrastructure. To that end, I ask that wireless hackers please study stub 802.11 code that DaveM wrote, posted at http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 From rl@hellgate.ch Thu Jun 3 03:35:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 03:35:38 -0700 (PDT) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53AZYgi016589 for ; Thu, 3 Jun 2004 03:35:35 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail2.bluewin.ch (Bluewin AG 7.0.028) id 40A468960022E376; Wed, 2 Jun 2004 11:58:31 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 1D7F98CA75E; Wed, 2 Jun 2004 13:58:32 +0200 (CEST) Date: Wed, 2 Jun 2004 13:58:32 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [4/9][PATCH 2.6] Nuke default_port, references to if_port, medialock Message-ID: <20040602115832.GA17509@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1507 Lines: 52 As is, code doesn't do anything useful. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -522,7 +522,6 @@ u16 chip_cmd; /* Current setting for ChipCmd */ /* These values are keep track of the transceiver/media in use. */ - unsigned int default_port:4; /* Last dev->if_port value. */ u8 tx_thresh, rx_thresh; /* MII transceiver section. */ @@ -810,7 +809,6 @@ if (option > 0) { if (option & 0x220) rp->mii_if.full_duplex = 1; - rp->default_port = option & 15; } if (card_idx < MAX_UNITS && full_duplex[card_idx] > 0) rp->mii_if.full_duplex = 1; @@ -859,10 +857,7 @@ if (option > 0) { if (option & 0x220) rp->mii_if.full_duplex = 1; - rp->default_port = option & 0x3ff; if (option & 0x330) { - /* FIXME: shouldn't someone check this variable? */ - /* rp->medialock = 1; */ printk(KERN_INFO " Forcing %dMbs %s-duplex " "operation.\n", (option & 0x300 ? 100 : 10), @@ -1061,9 +1056,6 @@ rp->rx_thresh = 0x60; /* Written in rhine_set_rx_mod/drivers/nete(). */ rp->mii_if.full_duplex = 0; - if (dev->if_port == 0) - dev->if_port = rp->default_port; - writel(rp->rx_ring_dma, ioaddr + RxRingPtr); writel(rp->tx_ring_dma, ioaddr + TxRingPtr); @@ -1254,8 +1246,6 @@ dev->name, readw(ioaddr + IntrStatus), mdio_read(dev, rp->phys[0], MII_BMSR)); - dev->if_port = 0; - /* protect against concurrent rx interrupts */ disable_irq(rp->pdev->irq); From kakadu_croc@yahoo.com Thu Jun 3 04:05:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 04:05:17 -0700 (PDT) Received: from web40904.mail.yahoo.com (web40904.mail.yahoo.com [66.218.78.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53B5Bgi017840 for ; Thu, 3 Jun 2004 04:05:11 -0700 Message-ID: <20040603110506.3996.qmail@web40904.mail.yahoo.com> Received: from [81.154.222.203] by web40904.mail.yahoo.com via HTTP; Thu, 03 Jun 2004 04:05:06 PDT Date: Thu, 3 Jun 2004 04:05:06 -0700 (PDT) From: Bradley Chapman Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support To: Jouni Malinen Cc: Netdev , Jean Tourrilhes , Jeff Garzik , Linux Kernel , hostap@shmoo.com, prism54-devel@prism54.org In-Reply-To: <20040603034458.GD7548@jm.kir.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kakadu_croc@yahoo.com Precedence: bulk X-list: netdev Content-Length: 732 Lines: 26 To all, I'm sorry to break into this thread, but I was just curious as to what will eventually happen to wpa_supplicant. Based upon Mr. Malinen's words, as well as what a few others in this thread have been saying, will WPA and 802.1x eventually become generalized driver frameworks in the kernel (like MII), using the current Crypto API and crypto drivers? I'm just asking from an enduser perspective here, because eventually I will be purchasing an 802.11g Prism54 device and would like to have an idea of the relative ease of configuring 802.1x and WPA in the future. Thanks, Brad ===== __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From rl@hellgate.ch Thu Jun 3 07:56:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 07:56:26 -0700 (PDT) Received: from mail5.bluewin.ch (mail5.bluewin.ch [195.186.1.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53EuNgi026753 for ; Thu, 3 Jun 2004 07:56:24 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail5.bluewin.ch (Bluewin AG 7.0.028) id 40A46B21002686CB; Wed, 2 Jun 2004 19:53:15 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 5A5958DFAE9; Wed, 2 Jun 2004 21:53:16 +0200 (CEST) Date: Wed, 2 Jun 2004 21:53:16 +0200 From: Roger Luethi To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [0/9][2.6] via-rhine patches Message-ID: <20040602195316.GA31791@k3.hellgate.ch> References: <20040602115703.GA16079@k3.hellgate.ch> <40BE2A90.7020508@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BE2A90.7020508@pobox.com> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 619 Lines: 16 On Wed, 02 Jun 2004 15:29:20 -0400, Jeff Garzik wrote: > Question -- are any of these needed for the 2.6.7 Release Candidate? No. Any significant change in driver behavior would be a bug. Patches submitted so far are clean-up in preparation for functional changes to come. > I prefer to defer these to post-2.6.7 as cleanup patches, since they are > not bug fixes. ACK. Please note, though, that I have another set of patches coming up which will be quite a bit more intrusive and will need review and wider testing. I plan to submit in time for 2.6.8-pre, even though some of it may not make it into 2.6.8. Roger From margitsw@t-online.de Thu Jun 3 08:32:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 08:32:11 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53FW4gi031141 for ; Thu, 3 Jun 2004 08:32:07 -0700 Received: from fwd06.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1BVuBG-0007Ze-00; Thu, 03 Jun 2004 17:30:58 +0200 Received: from margit.t-online.de (GuZH52Zb8ebnS6Uzf9KgukCl3EHEcTsVFq1Z+VhdBNM9YgYR3cHZ67@[80.128.220.230]) by fwd06.sul.t-online.com with esmtp id 1BVuAw-0LNgmW0; Thu, 3 Jun 2004 17:30:38 +0200 Message-Id: <5.1.0.14.2.20040603172343.00acf4a8@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Jun 2004 17:31:43 +0200 To: Jeff Garzik From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: [PATCH 6/17 linux-2.6.7-rc2] prism54: Kernel compatibility Cc: netdev@oss.sgi.com In-Reply-To: <40BE386A.1080201@pobox.com> References: <5.1.0.14.2.20040602221238.00adfbf8@pop.t-online.de> <200405310213.53280.margitsw@t-online.de> <200405310213.53280.margitsw@t-online.de> <5.1.0.14.2.20040602221238.00adfbf8@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Seen: false X-ID: GuZH52Zb8ebnS6Uzf9KgukCl3EHEcTsVFq1Z+VhdBNM9YgYR3cHZ67 X-archive-position: 5587 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: 1585 Lines: 50 At 16:28 02.06.2004 -0400, you wrote: >Margit Schubert-While wrote: >>At 16:03 02.06.2004 -0400, you wrote: >> >>>Margit Schubert-While wrote: >>> >>>>2004-03-20 Margit Schubert-While >>>>* isl_38xx.[ch], isl_ioctl.c, islpci_dev.[ch], islpci_eth.c >>>> islpci_hotplug.c, islpci_mgt.[ch], oid_mgt.c, prismcompat.h: >>>> Adopt new prism54 kernel compatibility. >>>> Remove remaining kernel version ifdefs. >>> >>> >>> >>>>@@ -325,11 +320,7 @@ >>>> printk(KERN_DEBUG "%s: uploading firmware...\n", >>>> priv->ndev->name); >>>> >>>> rc = isl38xx_upload_firmware(priv->firmware, >>>>-#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75)) >>>>- &priv->pdev->dev, >>>>-#else >>>>- pci_name(priv->pdev), >>>>-#endif >>> >>> >>>Rejected, both 2.4 and 2.6 should use pci_name() directly in the code >>> >>>Please resend patches 6 through 17, after fixing patches 6, 12, and 14. >>> >>> Jeff >>Absolutely not ! >>Parameter for 2.4 = char *, param for for 2.6 = struct dev * >>LOL >>Margit > >[jgarzik@sata repo]$ grep -w pci_name linux-2.[46]/include/linux/pci.h >linux-2.4/include/linux/pci.h:static inline char *pci_name(struct pci_dev >*pdev) >linux-2.6/include/linux/pci.h:static inline char *pci_name(struct pci_dev >*pdev) I was not talking about pci_name, I was talking about the 3rd param to request_firmware which is char * in 2.4, struct dev * in 2.6. Patch 16 cleans this area up. If it makes it easier, I can put together patches 5 and 16. Your call. Errm, what's wrong with patches 12 and 14 ? From jt@bougret.hpl.hp.com Thu Jun 3 09:52:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 09:52:44 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53Gqfgi001065 for ; Thu, 3 Jun 2004 09:52:41 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 60F794103C0; Thu, 3 Jun 2004 09:52:41 -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 JAA07261; Thu, 3 Jun 2004 09:53:33 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BVvSD-0002Ot-00; Thu, 03 Jun 2004 09:52:33 -0700 Date: Thu, 3 Jun 2004 09:52:33 -0700 To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040603165233.GC8770@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <20040602155542.GC24822@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602155542.GC24822@ruslug.rutgers.edu> 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: 5588 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: 1421 Lines: 32 On Wed, Jun 02, 2004 at 11:55:42AM -0400, Luis R. Rodriguez wrote: > On Wed, Jun 02, 2004 at 06:23:14AM -0700, Jouni Malinen wrote: > > > > The first thing I would like to see is an addition to Linux wireless > > extensions for WPA/WPA2 so that we can get rid of the private ioctls in > > the drivers. Even though these can often be similar, it would be nice to > > just write one driver interface code in wpa_supplicant and have it > > working with all Linu drivers.. I hope to find some time to write a > > proposal for this. > > I agree :). Jean? *poke* > > Luis The initial plan was for me to get more familiar with WPA, but this keep slipping (partly due to family matters). HP did follow my suggestions and use IPsec internally, which also explain why I'm in no hurry. There was some stuff I wanted to "improve" in the API design, but I guess that if I can't deliver a patch, I'd better shut up and try to avoid being a bottleneck. At this point, I think that Jouni is our best expert on the subject, and the fact that many driver has reused his API means that his API is sensible and flexible enough. So, the plan would be to take Jouni's API as is (or with minor modifications) and stuff that in wireless.h. I don't believe that the tools themselves need to be modified, because wpa_supplicant is the sole user of those ioctls. If you are all happy with that, then I'll just do it. Have fun... Jean From jt@bougret.hpl.hp.com Thu Jun 3 10:07:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 10:07:48 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53H7kgi001730 for ; Thu, 3 Jun 2004 10:07:46 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 45D7541442C; Thu, 3 Jun 2004 10:07:46 -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 KAA07841; Thu, 3 Jun 2004 10:08:45 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BVvgv-0002Vd-00; Thu, 03 Jun 2004 10:07:45 -0700 Date: Thu, 3 Jun 2004 10:07:45 -0700 To: Jeff Garzik Cc: Jouni Malinen , "Luis R. Rodriguez" , Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040603170745.GD8770@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <40BEA3CB.60908@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BEA3CB.60908@pobox.com> 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: 5589 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: 2107 Lines: 50 On Thu, Jun 03, 2004 at 12:06:35AM -0400, Jeff Garzik wrote: > > One of the things that is nice about wireless-2.6 is that is affords the > opportunity to totally rethink the wireless extensions. > > Although a lot of people would howl, since HostAP is essentially new > code from the mainline kernel perspective, a new userland API (and new > or updated tools) could come along with it. > > I have mentioned in the past (no offense Jean!) that I do not like the > overly-generic wireless handler structure. It is less type-safe than is > generally preferred in Linux, IMO. > > A low-level wireless driver should not implement ioctls, it should > implement callbacks in some sort of 'struct wireless_operations' as is > done in other kernel subsystems. > > ioctl details should be hidden from low-level drivers as much as > possible, through type-safe interfaces. Strive to make both the > wireless driver API and the wireless userland API easy to change and > evolve over time. > > Jeff Jeff, I'm amazed that you are so obsessed with this. Yes, Wireless Extension could be improved in millions ways, but at least it's working, whereas there are so many other areas where we have nothing at all. If you talk with most people developping wireless drivers, this doesn't even make their list. But I guess every one of us need to have his hot topic ;-) I believe most people are concerned about : o WPA support (and security API in general) o SNAP encapsulation/decapsualtion in kernel o handling 802.11 frames natively in kernel o handling 802.11 management in kernel (association/deassociation, ...) Personally, those are my priorities : o getting more wireless drivers in the kernel o RtNetlink API for Wireless Extensions I also explained you how you could wrap around Wireless Extension trivially to introduce a new driver API without breaking the many user space tools, so that you can implement your proposal with maximum backward compatibility. Just because there is one aspect of the API you don't like, we don't need to throw away the good parts. Have fun... Jean From rl@hellgate.ch Thu Jun 3 13:09:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 13:09:47 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i53K9fgi013593 for ; Thu, 3 Jun 2004 13:09:42 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD30023F73F; Wed, 2 Jun 2004 20:30:26 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 5575E8DFAE9; Wed, 2 Jun 2004 22:30:26 +0200 (CEST) Date: Wed, 2 Jun 2004 22:30:26 +0200 From: Roger Luethi To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Restructure reset code Message-ID: <20040602203026.GB31791@k3.hellgate.ch> References: <20040602115920.GA17634@k3.hellgate.ch> <40BE2DE0.4040102@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BE2DE0.4040102@pobox.com> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1915 Lines: 47 On Wed, 02 Jun 2004 15:43:28 -0400, Jeff Garzik wrote: > Roger Luethi wrote: > >Restructure code to make it easier to maintain. > > > >rhine_hw_init: resets chip, reloads eeprom > >rhine_chip_reset: chip reset + what used to be wait_for_reset > >rhine_reload_eeprom: reload eeprom, re-enable MMIO, disable > >EEPROM-controlled > > WOL > > > >Note: Chip reset clears a bunch of registers that should be reloaded > >from EEPROM (which turns off MMIO). Deal with that later. > > > Rejected, two reasons: > > 1) dev->dev_addr[] should be loaded from eeprom only once, at probe > time, not once for each hw init. [this value should be written to the > chip's MAC address registers upon each dev->open() call] We are in violent agreement, you are describing what the driver does with and without patch 9 (unless I seriously botched the splitting). Incidentally, rhine_hw_init gets called only once, at probe time (further calls are to rhine_chip_reset). The remaining problem with the reset stuff is this: Years ago, soft resets were added to via-rhine in the vain hope it would fix something, but soft resets overwrite some registers that need to be reloaded from somewhere (it's more than just the MAC address). The proper fix for this is to remove unnecessary soft resets (i.e. all but the one at probe time) and/or restore the registers affected by a soft reset. But that would go beyond a simple clean-up patch. > 2) Your "Note:" worries me... why not deal with this now? :) Mainly because I don't have all the information needed to positively determine the proper solution -- not yet. "Dealing with it" will likely mean removing two soft reset calls and documenting registers that are clobbered by soft reset (just in case), but that doesn't fit into a clean-up patch anyway. In summary, patch 9 is simply what all conceivable solutions have in common -- code clean-up. Thanks for the review. Roger From scott.feldman@intel.com Thu Jun 3 18:32:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 18:32:34 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i541WVgi026976 for ; Thu, 3 Jun 2004 18:32:31 -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 i541XjM9004335; Fri, 4 Jun 2004 01:33:45 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i541Sbe5030438; Fri, 4 Jun 2004 01:28:45 GMT Received: from [134.134.177.235] ([134.134.177.235]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060318322212780 ; Thu, 03 Jun 2004 18:32:22 -0700 Date: Thu, 3 Jun 2004 18:18:35 -0700 (PDT) From: Scott Feldman To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 2.4] e1000: fix napi crash on ifdown during traffic Message-ID: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 5591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 860 Lines: 25 Signed off by: Jesse Brandeburg diff -Naurp linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.mod/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-06-03 18:00:32.000000000 -0700 +++ linux-2.4/drivers/net/e1000.mod/e1000_main.c 2004-06-03 18:01:11.000000000 -0700 @@ -52,7 +52,7 @@ char e1000_driver_name[] = "e1000"; char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; -char e1000_driver_version[] = "5.2.52-k1"; +char e1000_driver_version[] = "5.2.52-k3"; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -2143,6 +2143,7 @@ e1000_clean(struct net_device *netdev, i if(work_done < work_to_do || !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); + return 0; } return (work_done >= work_to_do); From jesse.brandeburg@intel.com Thu Jun 3 18:42:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 18:43:08 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i541gugi027421 for ; Thu, 3 Jun 2004 18:42:57 -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 i541hinD014545; Fri, 4 Jun 2004 01:43:44 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i541hbho002321; Fri, 4 Jun 2004 01:43:46 GMT Received: from [134.134.177.235] ([134.134.177.235]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060318424924245 ; Thu, 03 Jun 2004 18:42:49 -0700 Date: Thu, 3 Jun 2004 18:29:04 -0700 (PDT) From: Jesse Brandeburg To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 2.5] e1000: fix napi crash on ifdown during traffic In-Reply-To: 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: 5592 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: 859 Lines: 24 Signed off by: Jesse Brandeburg diff -Naurp linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.mod/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-06-03 17:57:55.000000000 -0700 +++ linux-2.5/drivers/net/e1000.mod/e1000_main.c 2004-06-03 17:59:04.000000000 -0700 @@ -52,7 +52,7 @@ char e1000_driver_name[] = "e1000"; char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; -char e1000_driver_version[] = "5.2.52-k2"; +char e1000_driver_version[] = "5.2.52-k4"; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -2143,6 +2143,7 @@ e1000_clean(struct net_device *netdev, i if(work_done < work_to_do || !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); + return 0; } return (work_done >= work_to_do); From jm@jm.kir.nu Thu Jun 3 19:34:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 19:34:41 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i542Yagi002575 for ; Thu, 3 Jun 2004 19:34:36 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BW4Vz-0001zQ-G0; Thu, 03 Jun 2004 19:33:03 -0700 Date: Thu, 3 Jun 2004 19:33:03 -0700 From: Jouni Malinen To: jt@hpl.hp.com Cc: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040604023303.GB7537@jm.kir.nu> Mail-Followup-To: jt@hpl.hp.com, Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Linux Kernel References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <20040602155542.GC24822@ruslug.rutgers.edu> <20040603165233.GC8770@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040603165233.GC8770@bougret.hpl.hp.com> User-Agent: Mutt/1.5.6i X-archive-position: 5594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 2505 Lines: 46 On Thu, Jun 03, 2004 at 09:52:33AM -0700, Jean Tourrilhes wrote: > So, the plan would be to take Jouni's API as is (or with minor > modifications) and stuff that in wireless.h. I don't believe that the > tools themselves need to be modified, because wpa_supplicant is the > sole user of those ioctls. > If you are all happy with that, then I'll just do it. I'm mostly happy with this, but this should also include something from the private ioctls hostapd uses for AP functionality. In addition, I would consider changing couple of text based elements (e.g., WPA IE as hex string) to binary in order to remove extra parsing code and make the data contents smaller. I'm having quite a bit of problems with scan results getting too large for the current limit of 4 kB.. Admittedly, this is in a test lab environment, but still, it is annoying and requires workarounds like driver side filtering of the scan results. I could try to make a list of all private ioctls currently used in wpa_supplicant and hostapd, including some comments on what I would consider changing at this point (mostly, changing text binary for couple of cases and removing some fields that are not really going to be used). Main categories for new functionality would be: - key configuration (multiple algorithms, individual/unicast keys, packet number set/get), - WPA (or actually, generic) information element (get from scan results, set for (Re)AssocReq/Beacon/ProbeResp) - MLME requests (deauth/disassoc; maybe associate, too; I'm currently using SIOCSIWAP for this; scan request with SSID (and maybe also channel list) for active scanning - authentication mode/encryption algorithm parameters (Host AP driver does not current use this, but this is the way WPA drivers are used in Windows NDIS and some Linux driver authors prefered this option and wpa_supplicant supports it as an optional mechanism) - some encryption related events/parameters (reporting Michael MIC errors, TKIP countermeasures, configuration of "drop unencrypted" and "privacy invoked"). Once we get some kind of testing version done, I will add a new driver interface code for wpa_supplicant for the generic Linux wireless extensions case and modify Host AP driver to use this. I hope that other drivers would also start to use the new API at some point, although wpa_supplicant is likely to maintain the backwards compatible interface code for some time. -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Thu Jun 3 20:46:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 20:46:42 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i543kdgi007217 for ; Thu, 3 Jun 2004 20:46:39 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BW5dp-00028O-UF; Thu, 03 Jun 2004 20:45:13 -0700 Date: Thu, 3 Jun 2004 20:45:13 -0700 From: Jouni Malinen To: Jeff Garzik Cc: Netdev Subject: Re: Additional 802.11 net stack code posted Message-ID: <20040604034513.GD7537@jm.kir.nu> References: <40BECAFC.7040405@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BECAFC.7040405@pobox.com> User-Agent: Mutt/1.5.6i X-archive-position: 5595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 924 Lines: 21 On Thu, Jun 03, 2004 at 02:53:48AM -0400, Jeff Garzik wrote: > One of things that a proper "802.11 stack" should be is tie closely into > the core net stack, so that translation to/from 802.3 isn't going on all > the time. One wants to create, receive, and "understand" native 802.11 > frames, and provide a sane management infrastructure. Yes, indeed. When working outside the kernel tree, it was somewhat difficult to do this kind of changes, but this is certainly one of my goals, too, and now would be a good time to get the implementation together. > To that end, I ask that wireless hackers please study stub 802.11 code > that DaveM wrote Thanks! I will need to do some experimenting with this code, so this will take some time. Based on the quick browse through the files, there are number of things I have been missing before.. -- Jouni Malinen PGP id EFC895FA From russ@elegant-software.com Thu Jun 3 21:25:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jun 2004 21:25:48 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i544Pigi008219 for ; Thu, 3 Jun 2004 21:25:44 -0700 Received: from michael.elegant-software.com (pcp04414833pcs.nrockv01.md.comcast.net[69.140.188.59]) by comcast.net (rwcrmhc11) with ESMTP id <2004060402204101300cks3ie>; Fri, 4 Jun 2004 02:20:41 +0000 Received: from elegant-software.com (unknown [192.168.2.4]) by michael.elegant-software.com (Postfix) with ESMTP id 4B42E4781E; Thu, 3 Jun 2004 22:24:16 -0400 (EDT) Message-ID: <40BFDD4F.5080408@elegant-software.com> Date: Thu, 03 Jun 2004 22:24:15 -0400 From: Russell Leighton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Cc: Andrew Morton Subject: Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets? References: <20040531151843.7144dfce.akpm@osdl.org> In-Reply-To: <20040531151843.7144dfce.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: russ@elegant-software.com Precedence: bulk X-list: netdev Content-Length: 2276 Lines: 78 Thanks to all that helped me troubleshoot. Of the 2 issues I had with FedoraCore2, one problem is solved: * Multicast issues were solved by using another NIC. It seems that the driver for the NatSemi DP8381[56] does not receive mutlicast properly. * F_SETSIG still seems broken for TCP for me when my process sets up more than a few fd's...I will try the latest kernel to see if this goes away Russ Andrew Morton wrote: >Begin forwarded message: > >Date: Mon, 31 May 2004 14:45:08 -0400 >From: Russell Leighton >To: linux-kernel@vger.kernel.org >Subject: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets? > > > >I have a program that works fine under stock rh9 (2.4.2-8) but has >issues getting signaled under FedoraCore2 (2.6.5-1.358) >using SETSIG to a Posix RT signal. > >The program does the standard: > > /* hook to process */ > if ( fcntl(fdcallback->fd, F_SETOWN, mon->handler_q.thread->pid) == -1 ) { > aw_log(fdcallback->handler->logger, AW_ERROR_LOG_LEVEL, > "cannot set owner on fd (%s)", > strerror(errno)); > }/* end if */ > > /* make async */ > if ( fcntl(fdcallback->fd, F_SETFL, (O_NONBLOCK | O_ASYNC) ) == -1 ) { > aw_log(fdcallback->handler->logger, AW_ERROR_LOG_LEVEL, > "cannot set async on fd (%s)", > strerror(errno)); > }/* end if */ > > /* hook to signal */ > if ( fcntl(fdcallback->fd, F_SETSIG, AW_SIG_FD) == -1 ) { > aw_log(fdcallback->handler->logger, AW_ERROR_LOG_LEVEL, > "cannot set signal on fd (%s)", > strerror(errno)); > }/* end if */ > >Under Fedora things work well for raw sockets (much lower latency than >in 2.4!) but are inconsistent with udp or tcp sockets. > >In the udp case, I when I listen for multicast packets my app only >receives them when I am running a tcpdump (bizarre!). > >In the tcp case, I don't get signaled if I do the F_SETSIG on more than >1 fd. > >Any tips on tracking this down would be much appreciated. > >Thx > >Russ > >- >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 colin@colino.net Fri Jun 4 02:13:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 02:13:42 -0700 (PDT) Received: from srvsec1.girce.epro.fr (smtp-out.girce.epro.fr [195.6.195.146]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i549Dbgi019881 for ; Fri, 4 Jun 2004 02:13:38 -0700 Received: from ANOSP (unverified) by srvsec1.girce.epro.fr (Content Technologies SMTPRS 4.3.12) with SMTP id ; Fri, 4 Jun 2004 11:13:26 +0200 Message-ID: <026001c44a14$30cd9fc0$3cc8a8c0@epro.dom> From: "Colin LEROY" To: Cc: Subject: Re: wireless-2.6 queue opened Date: Fri, 4 Jun 2004 11:13:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-archive-position: 5598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin@colino.net Precedence: bulk X-list: netdev Content-Length: 341 Lines: 14 Hi, Just a quick question about the generic 802.11 stack. Is USB support planned for this? I'm asking, because I read on the web that adding USB support to hostap would be a lot of work: http://sisyphus.iocaine.com/pipermail/hostap/2004-March/006076.html -- Colin This message represents the official view of the voices in my head. From pp@ee.oulu.fi Fri Jun 4 02:48:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 02:48:02 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i549lxgi022575 for ; Fri, 4 Jun 2004 02:47:59 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id i4JAR1Rp003316; Wed, 19 May 2004 13:27:01 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i4JAR0Zb017541; Wed, 19 May 2004 13:27:00 +0300 (EEST) Date: Wed, 19 May 2004 13:27:00 +0300 From: Pekka Pietikainen To: Marc Herbert Cc: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: TxDescriptors -> 1024 default. Please not for every NIC! Message-ID: <20040519102700.GA16465@ee.oulu.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-MIME-Autoconverted: from 8bit to quoted-printable by ee.oulu.fi id i4JAR1Rp003316 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i549lxgi022575 X-archive-position: 5599 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: 1391 Lines: 27 On Wed, May 19, 2004 at 11:30:28AM +0200, Marc Herbert wrote: > - Me argues that we all lived happy for ages with this default > setting of 100packets @100Mb/s (and lived approximately happy @ > 10 Mb/s), but we'll soon see doom and gloom with this new and > brutal change to 1000packets for all this _legacy_ 10-100 Mb/s > hardware. e1000 data only is not enough to justify this radical > shift. > > If you are convinced by _both_ items above, then the patch below > content _both_, and we're done. > > If you are not, then... wait for further discussion, including answers > to latest Ricardo's post. Not to mention that not all modern hardware is gigabit, current 2.6 seems to be setting txqueuelen of 1000 for 802.11 devices too (at least my prism54), which might be causing major problems for me. Well, I'm still trying to figure out whether it's txqueue or WEP that causes all traffic to stop (with rx invalid crypt packets showing up in iwconfig afterwards, AP is a linksys wrt54g in case it makes a difference) every now and then until a ifdown / ifup. Tried both vanilla 2.6 prism54 and CVS (which seems to have a reset on tx timeout thing added), but if txqueue is 1000 that won't easily get triggered will it? It's been running for a few days just fine with txqueue = 100 and no WEP, if it stays like that i'll start tweaking to find what exactly triggers it. From jheffner@psc.edu Fri Jun 4 06:04:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 06:04:44 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54D4ggi003480 for ; Fri, 4 Jun 2004 06:04:42 -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 i54D4ef0004219 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 4 Jun 2004 09:04:40 -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 i54D4ew0004483 for ; Fri, 4 Jun 2004 09:04:40 -0400 (EDT) Date: Fri, 4 Jun 2004 09:04:40 -0400 (EDT) From: John Heffner To: Subject: OT: randomly unsubscribed 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: 5600 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: 10 I can't find an admin address for this list, sorry about the off-topic post. I'm getting randomly and silently unsubscribed from this list. It's happened three or four times now in the past few months. Could the list admin look in to this? Thanks, -John From c-d.hailfinger.kernel.2004@gmx.net Fri Jun 4 07:25:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 07:25:34 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54EPSgi013727 for ; Fri, 4 Jun 2004 07:25:28 -0700 Received: (qmail 2784 invoked by uid 65534); 4 Jun 2004 14:25:22 -0000 Received: from stud212245.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.245) by mail.gmx.net (mp017) with SMTP; 04 Jun 2004 16:25:22 +0200 X-Authenticated: #21910825 Message-ID: <40C0863E.9070508@gmx.net> Date: Fri, 04 Jun 2004 16:25:02 +0200 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: de, en MIME-Version: 1.0 To: smolny@o2.pl CC: foner+x-forcedeth@media.mit.edu, Manfred Spraul , Linux Kernel Mailing List , Andrew de Quincey , Netdev Subject: Re: Forcedeth and vesa References: <20040604135640.C218BD0B60@rekin6.o2.pl> In-Reply-To: <20040604135640.C218BD0B60@rekin6.o2.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Content-Length: 1083 Lines: 36 Hi, [foner: I included you in the CC because your problem seems similar.] smolny@o2.pl wrote: > Hi, > Sorry if you get this post by mistake. I found your address googling > for "forcedeth vesa". Well, you reached the right person. > When i use forcedeth module, both with 2.4.26 and 2.6.6 kernels, i > can't access vesa with mplayer. Just loading the module doesn't > cause the problem, only after i configure the net with ifconfig i > can't use vesa. This is interesting. Does the problem persist if you ifdown the interface? > If i use nvnet NVidia driver with 2.4.26, everything goes fine (no > nvnet for 2.6.x kernels). That is even more interesting. So the bug affects forcedeth, but not nvnet. Hmmm. We'll have to review the code again. > It's an EPOX 8RDA+ motherboard. Foner: Do you see similarities between your problem and this one? Janusz, Foner: Are you willing to test forcedeth with a few dozen iterations of patch, recompile, install, power down, power up and test again? I would send you patches to binary search the offending code. Regards, Carl-Daniel From tharbaugh@lnxi.com Fri Jun 4 07:31:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 07:31:27 -0700 (PDT) Received: from ash.lnxi.com (208.177.141.226.ptr.us.xo.net [208.177.141.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54EVHgi014130 for ; Fri, 4 Jun 2004 07:31:17 -0700 Received: (qmail 23667 invoked from network); 4 Jun 2004 14:31:32 -0000 Received: from tubarao.lnxi.com (HELO ?192.168.15.106?) (192.168.15.106) by ash.lnxi.com with SMTP; 4 Jun 2004 14:31:32 -0000 Subject: Re: [PATCH] abysmal e1000 performance (DITR) From: Thayne Harbaugh Reply-To: tharbaugh@lnxi.com To: netdev@oss.sgi.com Cc: ganesh.venkatesan@intel.com, Scott Feldman , Jesse Brandeburg In-Reply-To: <1086131111.20113.22.camel@tubarao> References: <1086131111.20113.22.camel@tubarao> Content-Type: text/plain Organization: Linux Networx Message-Id: <1086358801.23135.30.camel@tubarao> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 04 Jun 2004 08:20:02 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 5602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tharbaugh@lnxi.com Precedence: bulk X-list: netdev Content-Length: 335 Lines: 10 I have documented a serious performance problem with DITR in the e1000 driver. I have sent a patch to the netdev list as well as CC'ed various people at Intel. There has been very little response. I am wondering who has reviewed the DITR performance problem and what the plans are for fixing it. -- Thayne Harbaugh Linux Networx From adq_dvb@lidskialf.net Fri Jun 4 07:41:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 07:41:38 -0700 (PDT) Received: from beyond.lidskialf.net (lidskialf.net [62.3.233.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54EfWgi014758 for ; Fri, 4 Jun 2004 07:41:32 -0700 Received: from monstrousfish (monstrousfish [172.16.1.2]) by beyond.lidskialf.net (Postfix) with ESMTP id 6490F100977; Fri, 4 Jun 2004 15:41:26 +0100 (BST) From: Andrew de Quincey To: Carl-Daniel Hailfinger Subject: Re: Forcedeth and vesa Date: Fri, 4 Jun 2004 15:41:29 +0100 User-Agent: KMail/1.6.2 Cc: smolny@o2.pl, foner+x-forcedeth@media.mit.edu, Manfred Spraul , Linux Kernel Mailing List , Netdev References: <20040604135640.C218BD0B60@rekin6.o2.pl> <40C0863E.9070508@gmx.net> In-Reply-To: <40C0863E.9070508@gmx.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406041541.29594.adq_dvb@lidskialf.net> X-archive-position: 5603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adq_dvb@lidskialf.net Precedence: bulk X-list: netdev Content-Length: 1513 Lines: 43 On Friday 04 Jun 2004 15:25, Carl-Daniel Hailfinger wrote: > Hi, > > [foner: I included you in the CC because your problem seems similar.] > > smolny@o2.pl wrote: > > Hi, > > Sorry if you get this post by mistake. I found your address googling > > for "forcedeth vesa". > > Well, you reached the right person. > > > When i use forcedeth module, both with 2.4.26 and 2.6.6 kernels, i > > can't access vesa with mplayer. Just loading the module doesn't > > cause the problem, only after i configure the net with ifconfig i > > can't use vesa. > > This is interesting. Does the problem persist if you ifdown the interface? > > > If i use nvnet NVidia driver with 2.4.26, everything goes fine (no > > nvnet for 2.6.x kernels). > > That is even more interesting. So the bug affects forcedeth, but not > nvnet. Hmmm. We'll have to review the code again. > > > It's an EPOX 8RDA+ motherboard. > > Foner: Do you see similarities between your problem and this one? > > Janusz, Foner: Are you willing to test forcedeth with a few dozen > iterations of > patch, recompile, install, power down, power up and test again? > > I would send you patches to binary search the offending code. This is rather convenient. I have an Epox 8RDA+ as well. What video card are you using in that box? I'll install mplayer and see if I can replicate (I have an ATI 9800 Pro, but I can easily stuff a number of nvidia cards in there to check). If you're using an ATI or Nvidia card, are you using the proprietary or opensource drivers? From ganesh.venkatesan@intel.com Fri Jun 4 08:44:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 08:44:22 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54FiIgi019615 for ; Fri, 4 Jun 2004 08:44:18 -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 i54Fhg8J004179; Fri, 4 Jun 2004 15:43:42 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i54FiuSR028230; Fri, 4 Jun 2004 15:45:13 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060408441008809 ; Fri, 04 Jun 2004 08:44:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Jun 2004 08:44:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] abysmal e1000 performance (DITR) Date: Fri, 4 Jun 2004 08:44:08 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E014CEF36@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] abysmal e1000 performance (DITR) Thread-Index: AcRKQJhjQz7RypWwTTK+D7vFFxAXcwACfwgQ From: "Venkatesan, Ganesh" To: , Cc: "Feldman, Scott" , "Brandeburg, Jesse" X-OriginalArrivalTime: 04 Jun 2004 15:44:10.0345 (UTC) FILETIME=[C735E590:01C44A4A] 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 i54FiIgi019615 X-archive-position: 5604 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: 829 Lines: 32 Thayne: We are studying the patch and will get back to you once we have a plan to integrate it into the driver. Thanks, ganesh ------------------------------------------------- Ganesh Venkatesan Network/Storage Division, Hillsboro, OR -----Original Message----- From: Thayne Harbaugh [mailto:tharbaugh@lnxi.com] Sent: Friday, June 04, 2004 7:20 AM To: netdev@oss.sgi.com Cc: Venkatesan, Ganesh; Feldman, Scott; Brandeburg, Jesse Subject: Re: [PATCH] abysmal e1000 performance (DITR) I have documented a serious performance problem with DITR in the e1000 driver. I have sent a patch to the netdev list as well as CC'ed various people at Intel. There has been very little response. I am wondering who has reviewed the DITR performance problem and what the plans are for fixing it. -- Thayne Harbaugh Linux Networx From yoshfuji@linux-ipv6.org Fri Jun 4 09:52:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 09:52:49 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Gqigi021447 for ; Fri, 4 Jun 2004 09:52:44 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 114BF33CE5 for ; Sat, 5 Jun 2004 01:53:28 +0900 (JST) Resent-Date: Sat, 05 Jun 2004 01:53:27 +0900 (JST) Resent-Message-Id: <20040605.015327.131480818.yoshfuji@linux-ipv6.org> Resent-To: netdev@oss.sgi.com Resent-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) Date: Fri, 4 Jun 2004 17:54:23 +0200 From: "Wesley W. Terpstra" To: linux-kernel@vger.kernel.org Subject: Broken? 2.6.6 + IP_ADD_SOURCE_MEMBERSHIP + SO_REUSEADDR Message-ID: <20040604155423.GA5656@muffin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 5605 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: 1410 Lines: 37 Hi! I am using the new IGMPv3 support in the 2.6.* series for Single Source Multicast (SSM). However, the kernel appears to (incorrectly) drop packets in some situations. What I do is this: open a UDP port, set it SO_REUSEADDR, bind it to port 6767, and then use IP_ADD_SOURCE_MEMBERSHIP to listen to multicast group 232.65.43.21 and with a command-line controlled sender. If I launch the same program twice with different senders, the first program ceases to receive multicast packets. (Neither from its own sender, nor the second program's sender) The second program receives packets from its designated sender only (as expected). I know from tcpdump that the switch is delivering messages from the first designated sender. The kernel is simply not giving them to the application. Some more observations: If both programs specify the same sender, then both programs receive the message (as expected). This is not an issue with subscribing to multiple senders in general. A single program listening to two senders does receive messages from both. This seems like a bug to me. PS. I am not subscribed to this list, so please CC me. -- Wesley W. Terpstra - 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 Fri Jun 4 09:55:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 09:55:04 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Gt0gi021776 for ; Fri, 4 Jun 2004 09:55:00 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9901D33CE5; Sat, 5 Jun 2004 01:55:44 +0900 (JST) Date: Sat, 05 Jun 2004 01:55:44 +0900 (JST) Message-Id: <20040605.015544.102223977.yoshfuji@linux-ipv6.org> To: terpstra@gkec.tu-darmstadt.de Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com, yoshfuji@linux-ipv6.org Subject: Re: Broken? 2.6.6 + IP_ADD_SOURCE_MEMBERSHIP + SO_REUSEADDR From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040604155423.GA5656@muffin> References: <20040604155423.GA5656@muffin> 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: 5606 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: 1136 Lines: 30 In article <20040604155423.GA5656@muffin> (at Fri, 4 Jun 2004 17:54:23 +0200), "Wesley W. Terpstra" says: > If I launch the same program twice with different senders, the first program > ceases to receive multicast packets. (Neither from its own sender, nor the > second program's sender) The second program receives packets from its > designated sender only (as expected). : > If both programs specify the same sender, then both programs receive the > message (as expected). Thanks for the report. The following patch should fix the issue. Please try. Thanks again. ===== net/ipv4/udp.c 1.60 vs edited ===== --- 1.60/net/ipv4/udp.c 2004-05-31 03:57:26 +09:00 +++ edited/net/ipv4/udp.c 2004-06-05 01:47:07 +09:00 @@ -294,7 +294,7 @@ ipv6_only_sock(s) || (s->sk_bound_dev_if && s->sk_bound_dev_if != dif)) continue; - if (!ip_mc_sf_allow(sk, loc_addr, rmt_addr, dif)) + if (!ip_mc_sf_allow(s, loc_addr, rmt_addr, dif)) continue; goto found; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ralf@linux-mips.org Fri Jun 4 10:12:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 10:12:32 -0700 (PDT) Received: from mail.linux-mips.net (p508B7FF6.dip.t-dialin.net [80.139.127.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54HCTgi028611 for ; Fri, 4 Jun 2004 10:12:30 -0700 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i54HCP21021803; Fri, 4 Jun 2004 19:12:25 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i54HCPMv021802; Fri, 4 Jun 2004 19:12:25 +0200 Date: Fri, 4 Jun 2004 19:12:25 +0200 From: Ralf Baechle To: John Heffner Cc: netdev@oss.sgi.com Subject: Re: OT: randomly unsubscribed Message-ID: <20040604171225.GB15486@linux-mips.org> References: 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: 5607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 780 Lines: 19 On Fri, Jun 04, 2004 at 09:04:40AM -0400, John Heffner wrote: > I can't find an admin address for this list, sorry about the off-topic > post. Ever heared about postmaster? > I'm getting randomly and silently unsubscribed from this list. It's > happened three or four times now in the past few months. Could the list > admin look in to this? Subscribers will be unsubscribed if a there the number of bounces exceeds a certain threshold. The bounce filter is not able to distinguish between "real" bounces and false bounces such caused by sender address forgery by viruses and spam. As you can imagine due the massive abuse of email by spam and viruses this is going to cause problems ... For now I've double the number of bounces before a user gets unsubscribed. Ralf From yoshfuji@linux-ipv6.org Fri Jun 4 10:13:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 10:13:32 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54HDRgi028970 for ; Fri, 4 Jun 2004 10:13:28 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9E90B33CE5; Sat, 5 Jun 2004 02:14:11 +0900 (JST) Date: Sat, 05 Jun 2004 02:14:11 +0900 (JST) Message-Id: <20040605.021411.55160771.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Broken? 2.6.6 + IP_ADD_SOURCE_MEMBERSHIP + SO_REUSEADDR From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040605.015544.102223977.yoshfuji@linux-ipv6.org> References: <20040604155423.GA5656@muffin> <20040605.015544.102223977.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: 5608 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: 695 Lines: 20 In article <20040605.015544.102223977.yoshfuji@linux-ipv6.org> (at Sat, 05 Jun 2004 01:55:44 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > The following patch should fix the issue. Please try. And, here's a variant for 2.4. ===== net/ipv4/udp.c 1.13 vs edited ===== --- 1.13/net/ipv4/udp.c 2004-02-22 06:12:49 +09:00 +++ edited/net/ipv4/udp.c 2004-06-05 01:56:50 +09:00 @@ -290,7 +290,7 @@ ipv6_only_sock(s) || (s->bound_dev_if && s->bound_dev_if != dif)) continue; - if (!ip_mc_sf_allow(sk, loc_addr, rmt_addr, dif)) + if (!ip_mc_sf_allow(s, loc_addr, rmt_addr, dif)) continue; break; } -- yoshfuji @ time to sleep... From jt@bougret.hpl.hp.com Fri Jun 4 11:01:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 11:01:58 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54I1lgi030964 for ; Fri, 4 Jun 2004 11:01:48 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 6253240FBCD; Fri, 4 Jun 2004 11:01:07 -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 LAA23199; Fri, 4 Jun 2004 11:02:08 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BWJ06-00055v-00; Fri, 04 Jun 2004 11:01:06 -0700 Date: Fri, 4 Jun 2004 11:01:06 -0700 To: Netdev , hostap@shmoo.com, prism54-devel@prism54.org, Jeff Garzik , Linux Kernel Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support Message-ID: <20040604180106.GA19181@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040602071449.GJ10723@ruslug.rutgers.edu> <20040602132313.GB7341@jm.kir.nu> <20040602155542.GC24822@ruslug.rutgers.edu> <20040603165233.GC8770@bougret.hpl.hp.com> <20040604023303.GB7537@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040604023303.GB7537@jm.kir.nu> 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: 5609 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: 2074 Lines: 48 On Thu, Jun 03, 2004 at 07:33:03PM -0700, Jouni Malinen wrote: > On Thu, Jun 03, 2004 at 09:52:33AM -0700, Jean Tourrilhes wrote: > > > So, the plan would be to take Jouni's API as is (or with minor > > modifications) and stuff that in wireless.h. I don't believe that the > > tools themselves need to be modified, because wpa_supplicant is the > > sole user of those ioctls. > > If you are all happy with that, then I'll just do it. > > I'm mostly happy with this, but this should also include something from > the private ioctls hostapd uses for AP functionality. Obviously we need the full functionality, not just some part of it. > In addition, I would consider changing couple of text based elements > (e.g., WPA IE as hex string) to binary in order to remove extra > parsing code and make the data contents smaller. The downside of that is that things need to be predefined. As we are doing a "WPA API" and not a "generic link layer security API", that's OK. The other thing you may want to think about is miving all string/arrays at the end of the definition so that we can grow them easily if needed, and so that the first part can be fixed. > I'm having quite a bit of problems with scan > results getting too large for the current limit of 4 kB.. Admittedly, > this is in a test lab environment, but still, it is annoying and > requires workarounds like driver side filtering of the scan results. That's easy to fix. I did the same with "iwpriv" definitions a couple of weeks ago. Basically, you return -E2BIG to user space until userspace give you a big enough buffer. I'll try to fix that. > I could try to make a list of all private ioctls currently used in > wpa_supplicant and hostapd, including some comments on what I would > consider changing at this point (mostly, changing text binary for couple > of cases and removing some fields that are not really going to be used). You currently have your plate pretty full. I'll try to help, but my first son was born one month ago and things are not as smooth as planned. > Jouni Malinen Jean From sri@us.ibm.com Fri Jun 4 11:44:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 11:45:05 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Iiogi004617 for ; Fri, 4 Jun 2004 11:44:56 -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.2) with ESMTP id i54IiNwc704198; Fri, 4 Jun 2004 14:44:23 -0400 Received: from w-sridhar.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 i54IiCir224732; Fri, 4 Jun 2004 12:44:23 -0600 Date: Fri, 4 Jun 2004 11:44:12 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [BK PATCH] 2.6 and 2.4 SCTP updates. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5610 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: 14514 Lines: 437 Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work & bk pull http://linux-lksctp.bkbits.net/lksctp-2.4.work to get the following bugfix csets to 2.6 and 2.4 SCTP. Thanks Sridhar # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/03 17:46:29-07:00 sri@us.ibm.com # [SCTP] Fix poll() on a 1-1 style socket so that it returns when the # association is aborted by peer. # # net/sctp/sm_sideeffect.c # # ChangeSet # 2004/06/03 17:40:49-07:00 sri@us.ibm.com # [SCTP] Fix to wakeup blocking connect() after max INIT retries failed. # # net/sctp/socket.c # net/sctp/sm_sideeffect.c # # ChangeSet # 2004/06/03 17:33:41-07:00 sri@us.ibm.com # [SCTP] Fix missing VTAG validation on certain incoming packets. # # net/sctp/sm_statefuns.c # include/net/sctp/sm.h # # ChangeSet # 2004/06/03 17:26:13-07:00 sri@us.ibm.com # [SCTP] Fix the use of cached non-zero vtag in an INIT that is resent # after a stale cookie error. # # net/sctp/sm_statefuns.c # net/sctp/sm_sideeffect.c # include/net/sctp/command.h # # ChangeSet # 2004/06/03 17:19:57-07:00 jhh@lucent.com # [SCTP] Fix to not start a new association on a 1-many style sendmsg() # with MSG_EOF/MSG_ABORT flag and no data. # # net/sctp/socket.c # # ChangeSet # 2004/06/03 17:16:07-07:00 jhh@lucent.com # [SCTP] Fix to not setup a new association if the endpoint is in # SHUTDOWN_ACK_SENT state and recognizes that the peer has restarted. # # net/sctp/sm_statefuns.c # diff -Nru a/include/net/sctp/command.h b/include/net/sctp/command.h --- a/include/net/sctp/command.h Fri Jun 4 11:08:18 2004 +++ b/include/net/sctp/command.h Fri Jun 4 11:08:18 2004 @@ -93,6 +93,7 @@ SCTP_CMD_PROCESS_OPERR, /* Process an ERROR chunk. */ SCTP_CMD_REPORT_FWDTSN, /* Report new cumulative TSN Ack. */ SCTP_CMD_PROCESS_FWDTSN, /* Skips were reported, so process further. */ + SCTP_CMD_CLEAR_INIT_TAG, /* Clears association peer's inittag. */ SCTP_CMD_LAST } sctp_verb_t; diff -Nru a/include/net/sctp/sm.h b/include/net/sctp/sm.h --- a/include/net/sctp/sm.h Fri Jun 4 11:08:18 2004 +++ b/include/net/sctp/sm.h Fri Jun 4 11:08:18 2004 @@ -440,6 +440,23 @@ BUG(); } +/* Check VTAG of the packet matches the sender's own tag. */ +static inline int +sctp_vtag_verify(const struct sctp_chunk *chunk, + const struct sctp_association *asoc) +{ + /* RFC 2960 Sec 8.5 When receiving an SCTP packet, the endpoint + * MUST ensure that the value in the Verification Tag field of + * the received SCTP packet matches its own Tag. If the received + * Verification Tag value does not match the receiver's own + * tag value, the receiver shall silently discard the packet... + */ + if (ntohl(chunk->sctp_hdr->vtag) == asoc->c.my_vtag) + return 1; + + return 0; +} + /* Check VTAG of the packet matches the sender's own tag OR its peer's * tag and the T bit is set in the Chunk Flags. */ diff -Nru a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c --- a/net/sctp/sm_sideeffect.c Fri Jun 4 11:08:18 2004 +++ b/net/sctp/sm_sideeffect.c Fri Jun 4 11:08:18 2004 @@ -429,6 +429,9 @@ sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(event)); + sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, + SCTP_STATE(SCTP_STATE_CLOSED)); + /* SEND_FAILED sent later when cleaning up the association. */ asoc->outqueue.error = error; sctp_add_cmd_sf(commands, SCTP_CMD_DELETE_TCB, SCTP_NULL()); @@ -457,6 +460,10 @@ sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, SCTP_STATE(SCTP_STATE_CLOSED)); + /* Set sk_err to ECONNRESET on a 1-1 style socket. */ + if (!sctp_style(asoc->base.sk, UDP)) + asoc->base.sk->sk_err = ECONNRESET; + /* SEND_FAILED sent later when cleaning up the association. */ asoc->outqueue.error = error; sctp_add_cmd_sf(commands, SCTP_CMD_DELETE_TCB, SCTP_NULL()); @@ -1271,6 +1278,9 @@ case SCTP_CMD_PROCESS_OPERR: sctp_cmd_process_operr(commands, asoc, chunk); + break; + case SCTP_CMD_CLEAR_INIT_TAG: + asoc->peer.i.init_tag = 0; break; default: printk(KERN_WARNING "Impossible command: %u, %p\n", diff -Nru a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c --- a/net/sctp/sm_statefuns.c Fri Jun 4 11:08:18 2004 +++ b/net/sctp/sm_statefuns.c Fri Jun 4 11:08:18 2004 @@ -171,7 +171,7 @@ * Verification Tag field to Tag_A, and also provide its own * Verification Tag (Tag_Z) in the Initiate Tag field. * - * Verification Tag: No checking. + * Verification Tag: Must be 0. * * Inputs * (endpoint, asoc, chunk) @@ -219,6 +219,12 @@ (sk->sk_ack_backlog >= sk->sk_max_ack_backlog))) return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands); + /* 3.1 A packet containing an INIT chunk MUST have a zero Verification + * Tag. + */ + if (chunk->sctp_hdr->vtag != 0) + return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands); + /* Verify the INIT chunk before processing it. */ err_chunk = NULL; if (!sctp_verify_init(asoc, chunk->chunk_hdr->type, @@ -377,6 +383,9 @@ if (!chunk->singleton) return SCTP_DISPOSITION_VIOLATION; + if (!sctp_vtag_verify(chunk, asoc)) + return sctp_sf_pdiscard(ep, asoc, type, arg, commands); + /* Grab the INIT header. */ chunk->subh.init_hdr = (sctp_inithdr_t *) chunk->skb->data; @@ -659,8 +668,12 @@ const sctp_subtype_t type, void *arg, sctp_cmd_seq_t *commands) { + struct sctp_chunk *chunk = arg; struct sctp_ulpevent *ev; + if (!sctp_vtag_verify(chunk, asoc)) + return sctp_sf_pdiscard(ep, asoc, type, arg, commands); + /* RFC 2960 5.1 Normal Establishment of an Association * * E) Upon reception of the COOKIE ACK, endpoint "A" will move @@ -807,13 +820,7 @@ struct sctp_chunk *reply; size_t paylen = 0; - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. If the received - * Verification Tag value does not match the receiver's own - * tag value, the receiver shall silently discard the packet... - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); /* 8.3 The receiver of the HEARTBEAT should immediately @@ -876,11 +883,7 @@ sctp_sender_hb_info_t *hbinfo; unsigned long max_interval; - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. ... - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); hbinfo = (sctp_sender_hb_info_t *) chunk->skb->data; @@ -1130,6 +1133,12 @@ if (!chunk->singleton) return SCTP_DISPOSITION_VIOLATION; + /* 3.1 A packet containing an INIT chunk MUST have a zero Verification + * Tag. + */ + if (chunk->sctp_hdr->vtag != 0) + return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands); + /* Grab the INIT header. */ chunk->subh.init_hdr = (sctp_inithdr_t *) chunk->skb->data; @@ -1386,6 +1395,8 @@ sctp_init_chunk_t *peer_init; struct sctp_ulpevent *ev; struct sctp_chunk *repl; + struct sctp_chunk *err; + sctp_disposition_t disposition; /* new_asoc is a brand-new association, so these are not yet * side effects--it is safe to run them here. @@ -1405,6 +1416,29 @@ return SCTP_DISPOSITION_CONSUME; } + /* If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes + * the peer has restarted (Action A), it MUST NOT setup a new + * association but instead resend the SHUTDOWN ACK and send an ERROR + * chunk with a "Cookie Received while Shutting Down" error cause to + * its peer. + */ + if (sctp_state(asoc, SHUTDOWN_ACK_SENT)) { + disposition = sctp_sf_do_9_2_reshutack(ep, asoc, + SCTP_ST_CHUNK(chunk->chunk_hdr->type), + chunk, commands); + if (SCTP_DISPOSITION_NOMEM == disposition) + goto nomem; + + err = sctp_make_op_error(asoc, chunk, + SCTP_ERROR_COOKIE_IN_SHUTDOWN, + NULL, 0); + if (err) + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, + SCTP_CHUNK(err)); + + return SCTP_DISPOSITION_CONSUME; + } + /* For now, fail any unsent/unacked data. Consider the optional * choice of resending of this data. */ @@ -1883,6 +1917,9 @@ sctp_addto_chunk(reply, sizeof(bht), &bht); + /* Clear peer's init_tag cached in assoc as we are sending a new INIT */ + sctp_add_cmd_sf(commands, SCTP_CMD_CLEAR_INIT_TAG, SCTP_NULL()); + /* Cast away the const modifier, as we want to just * rerun it through as a sideffect. */ @@ -2071,13 +2108,7 @@ skb_pull(chunk->skb, sizeof(sctp_shutdownhdr_t)); chunk->subh.shutdown_hdr = sdh; - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. If the received - * Verification Tag value does not match the receiver's own - * tag value, the receiver shall silently discard the packet... - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); /* Upon the reception of the SHUTDOWN, the peer endpoint shall @@ -2190,13 +2221,7 @@ sctp_cwrhdr_t *cwr; struct sctp_chunk *chunk = arg; - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. If the received - * Verification Tag value does not match the receiver's own - * tag value, the receiver shall silently discard the packet... - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); cwr = (sctp_cwrhdr_t *) chunk->skb->data; @@ -2246,13 +2271,7 @@ sctp_ecnehdr_t *ecne; struct sctp_chunk *chunk = arg; - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. If the received - * Verification Tag value does not match the receiver's own - * tag value, the receiver shall silently discard the packet... - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); ecne = (sctp_ecnehdr_t *) chunk->skb->data; @@ -2309,13 +2328,7 @@ int tmp; __u32 tsn; - /* RFC 2960 8.5 Verification Tag - * - * When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) { + if (!sctp_vtag_verify(chunk, asoc)) { sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG, SCTP_NULL()); return sctp_sf_pdiscard(ep, asoc, type, arg, commands); @@ -2569,13 +2582,7 @@ int tmp; __u32 tsn; - /* RFC 2960 8.5 Verification Tag - * - * When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) { + if (!sctp_vtag_verify(chunk, asoc)) { sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG, SCTP_NULL()); return sctp_sf_pdiscard(ep, asoc, type, arg, commands); @@ -2745,11 +2752,7 @@ sctp_sackhdr_t *sackh; __u32 ctsn; - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. ... - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); /* Pull the SACK chunk from the data buffer */ @@ -2895,6 +2898,9 @@ struct sctp_chunk *reply; struct sctp_ulpevent *ev; + if (!sctp_vtag_verify(chunk, asoc)) + return sctp_sf_pdiscard(ep, asoc, type, arg, commands); + /* 10.2 H) SHUTDOWN COMPLETE notification * * When SCTP completes the shutdown procedures (section 9.2) this @@ -3229,13 +3235,7 @@ __u16 len; __u32 tsn; - /* RFC 2960 8.5 Verification Tag - * - * When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) { + if (!sctp_vtag_verify(chunk, asoc)) { sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG, SCTP_NULL()); return sctp_sf_pdiscard(ep, asoc, type, arg, commands); @@ -3293,13 +3293,7 @@ __u16 len; __u32 tsn; - /* RFC 2960 8.5 Verification Tag - * - * When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. - */ - if (ntohl(chunk->sctp_hdr->vtag) != asoc->c.my_vtag) { + if (!sctp_vtag_verify(chunk, asoc)) { sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG, SCTP_NULL()); return sctp_sf_pdiscard(ep, asoc, type, arg, commands); @@ -3376,13 +3370,7 @@ SCTP_DEBUG_PRINTK("Processing the unknown chunk id %d.\n", type.chunk); - /* 8.5 When receiving an SCTP packet, the endpoint MUST ensure - * that the value in the Verification Tag field of the - * received SCTP packet matches its own Tag. If the received - * Verification Tag value does not match the receiver's own - * tag value, the receiver shall silently discard the packet. - */ - if (ntohl(unk_chunk->sctp_hdr->vtag) != asoc->c.my_vtag) + if (!sctp_vtag_verify(unk_chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); switch (type.chunk & SCTP_CID_ACTION_MASK) { diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c Fri Jun 4 11:08:18 2004 +++ b/net/sctp/socket.c Fri Jun 4 11:08:18 2004 @@ -1164,6 +1164,11 @@ if (!asoc) { SCTP_DEBUG_PRINTK("There is no association yet.\n"); + if (sinfo_flags & (MSG_EOF | MSG_ABORT)) { + err = -EINVAL; + goto out_unlock; + } + /* Check for invalid stream against the stream counts, * either the default or the user specified stream counts. */ @@ -4388,7 +4393,11 @@ return err; do_error: - err = -ECONNREFUSED; + if (asoc->counters[SCTP_COUNTER_INIT_ERROR] + 1 >= + asoc->max_init_attempts) + err = -ETIMEDOUT; + else + err = -ECONNREFUSED; goto out; do_interrupted: From Gary.Spiess@Intermec.com Fri Jun 4 12:53:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 12:53:20 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54JrGgi016728 for ; Fri, 4 Jun 2004 12:53:16 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id OAA00336; Fri, 4 Jun 2004 14:53:03 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i54MsFKJ023538; Fri, 4 Jun 2004 17:54:15 -0500 Message-ID: <200406041453030734.0BC334E5@136.179.85.112> In-Reply-To: <40B786A5.80506@colorfullife.com> References: <200405280142110234.0D95EB69@136.179.85.112> <40B786A5.80506@colorfullife.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 04 Jun 2004 14:53:03 -0500 From: "Gary N Spiess" To: netdev@oss.sgi.com Cc: manfred@colorfullife.com Subject: [PATCH] natsemi update 2/4 Ethtool ioctl fixes & enhancements Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_1086378783491=_" X-archive-position: 5611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 9698 Lines: 172 --=====_1086378783491=_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Jeff, This is the second of a series of patches needed to support our product= using the DP83815. This patch fixes some of the ethtool ioctl support. It does a better job= of switching autonegotiation/speed/duplex parameters. It no longer= reports failure to complete negotiation when auto negotiation was= disabled. Attempts to return the MII registers from the MII interface,= rather than always using the internal registers. Formally set PORT_MII as= XCVR_EXTERNAL and PORT_TP as XCVR_INTERNAL. Gary oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 --=====_1086378783491=_ Content-Type: application/octet-stream; name="natsemi-2.6.6-2.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="natsemi-2.6.6-2.patch" LS0tIGxpbnV4LTIuNi42L2RyaXZlcnMvbmV0L25hdHNlbWkuYwkyMDA0LTA2 LTAzIDE0OjIwOjI4LjAwMDAwMDAwMCAtMDUwMAorKysgbGludXgvZHJpdmVy cy9uZXQvbmF0c2VtaS5jCTIwMDQtMDYtMDMgMTQ6MjY6MzkuMDAwMDAwMDAw IC0wNTAwCkBAIC01OTksNyArNTk5LDcgQEAKIH07CiAKIGVudW0gUGh5Q3Ry bF9iaXRzIHsKLQlQaHlBZGRyTWFzawkJPSAweGYsCisJUGh5QWRkck1hc2sJ CT0gMHgxZiwKIH07CiAKIC8qIHZhbHVlcyB3ZSBtaWdodCBmaW5kIGluIHRo ZSBzaWxpY29uIHJldmlzaW9uIHJlZ2lzdGVyICovCkBAIC02NjIsNiArNjYy LDcgQEAKIAkvKiBEbyBub3QgdG91Y2ggdGhlIG5pYyByZWdpc3RlcnMgKi8K IAlpbnQgaGFuZHNfb2ZmOwogCS8qIFRoZXNlIHZhbHVlcyBhcmUga2VlcCB0 cmFjayBvZiB0aGUgdHJhbnNjZWl2ZXIvbWVkaWEgaW4gdXNlICovCisJaW50 IHBoeV9hZGRyX2V4dGVybmFsOwogCXVuc2lnbmVkIGludCBmdWxsX2R1cGxl eDsKIAkvKiBSeCBmaWx0ZXIgKi8KIAl1MzIgY3VyX3J4X21vZGU7CkBAIC0x MjQ5LDE1ICsxMjUwLDE3IEBACiAJbG9uZyBpb2FkZHIgPSBkZXYtPmJhc2Vf YWRkcjsKIAlpbnQgaTsKIAotCWZvciAoaT0wO2k8TkFUU0VNSV9IV19USU1F T1VUO2krKykgewotCQlpZiAocmVhZGwoZGV2LT5iYXNlX2FkZHIgKyBDaGlw Q29uZmlnKSAmIENmZ0FuZWdEb25lKQotCQkJYnJlYWs7Ci0JCXVkZWxheSgx MCk7Ci0JfQotCWlmIChpPT1OQVRTRU1JX0hXX1RJTUVPVVQgJiYgbmV0aWZf bXNnX2xpbmsobnApKSB7Ci0JCXByaW50ayhLRVJOX0lORk8KLQkJCSIlczog YXV0b25lZ290aWF0aW9uIGRpZCBub3QgY29tcGxldGUgaW4gJWQgdXNlYy5c biIsCi0JCQlkZXYtPm5hbWUsIGkqMTApOworCWlmIChtZGlvX3JlYWQoZGV2 LCAxLCBNSUlfQk1DUikgJiBCTUNSX0FORU5BQkxFKSB7CisJCWZvciAoaT0w O2k8TkFUU0VNSV9IV19USU1FT1VUO2krKykgeworCQkJaWYgKG1kaW9fcmVh ZChkZXYsIDEsIE1JSV9CTVNSKSAmIEJNU1JfQU5FR0NPTVBMRVRFKQorCQkJ CWJyZWFrOworCQkJdWRlbGF5KDEwKTsKKwkJfQorCQlpZiAoaT09TkFUU0VN SV9IV19USU1FT1VUICYmIG5ldGlmX21zZ19saW5rKG5wKSkgeworCQkJcHJp bnRrKEtFUk5fSU5GTworCQkJCSIlczogYXV0b25lZ290aWF0aW9uIGRpZCBu b3QgY29tcGxldGUgaW4gJWQgdXNlYy5cbiIsCisJCQkJZGV2LT5uYW1lLCBp KjEwKTsKKwkJfQogCX0KIAogCS8qIE9uIHBhZ2UgNzggb2YgdGhlIHNwZWMs IHRoZXkgcmVjb21tZW5kIHNvbWUgc2V0dGluZ3MgZm9yICJvcHRpbXVtCkBA IC0yMjcxLDYgKzIyNzQsNyBAQAogCiBzdGF0aWMgaW50IG5ldGRldl9nZXRf ZWNtZChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgZXRodG9vbF9j bWQgKmVjbWQpCiB7CisJc3RydWN0IG5ldGRldl9wcml2YXRlICpucCA9IGRl di0+cHJpdjsKIAl1MzIgdG1wOwogCiAJZWNtZC0+c3VwcG9ydGVkID0KQEAg LTIyNzgsMjAgKzIyODIsMjEgQEAKIAkJU1VQUE9SVEVEXzEwMGJhc2VUX0hh bGYgfCBTVVBQT1JURURfMTAwYmFzZVRfRnVsbCB8CiAJCVNVUFBPUlRFRF9B dXRvbmVnIHwgU1VQUE9SVEVEX1RQIHwgU1VQUE9SVEVEX01JSSk7CiAKLQkv KiBvbmx5IHN1cHBvcnRzIHR3aXN0ZWQtcGFpciBvciBNSUkgKi8KLQl0bXAg PSByZWFkbChkZXYtPmJhc2VfYWRkciArIENoaXBDb25maWcpOwotCWlmICh0 bXAgJiBDZmdFeHRQaHkpCi0JCWVjbWQtPnBvcnQgPSBQT1JUX01JSTsKLQll bHNlCi0JCWVjbWQtPnBvcnQgPSBQT1JUX1RQOwotCi0JLyogb25seSBzdXBw b3J0cyBpbnRlcm5hbCB0cmFuc2NlaXZlciAqLwotCWVjbWQtPnRyYW5zY2Vp dmVyID0gWENWUl9JTlRFUk5BTDsKLQotCS8qIG5vdCBzdXJlIHdoYXQgdGhp cyBpcyBmb3IgKi8KLQllY21kLT5waHlfYWRkcmVzcyA9IHJlYWR3KGRldi0+ YmFzZV9hZGRyICsgUGh5Q3RybCkgJiBQaHlBZGRyTWFzazsKKwkvKiBSZXR1 cm4gdGhlIHRyYW5zY2VpdmVyIHR5cGUgKi8KKwlzd2l0Y2ggKGRldi0+aWZf cG9ydCkgeworCWRlZmF1bHQ6CisJY2FzZSBQT1JUX1RQOgorCQllY21kLT5h ZHZlcnRpc2luZyA9IEFEVkVSVElTRURfVFA7CisJCWVjbWQtPnRyYW5zY2Vp dmVyID0gWENWUl9JTlRFUk5BTDsKKwkJYnJlYWs7CisJY2FzZSBQT1JUX01J SToKKwkJZWNtZC0+YWR2ZXJ0aXNpbmcgPSBBRFZFUlRJU0VEX01JSTsKKwkJ ZWNtZC0+dHJhbnNjZWl2ZXIgPSBYQ1ZSX0VYVEVSTkFMOworCQlicmVhazsK Kwl9CisJZWNtZC0+cG9ydCA9IGRldi0+aWZfcG9ydDsKKwllY21kLT5waHlf YWRkcmVzcyA9IG5wLT5waHlfYWRkcl9leHRlcm5hbDsKIAotCWVjbWQtPmFk dmVydGlzaW5nID0gQURWRVJUSVNFRF9UUCB8IEFEVkVSVElTRURfTUlJOwog CXRtcCA9IG1kaW9fcmVhZChkZXYsIDEsIE1JSV9BRFZFUlRJU0UpOwogCWlm ICh0bXAgJiBBRFZFUlRJU0VfMTBIQUxGKQogCQllY21kLT5hZHZlcnRpc2lu ZyB8PSBBRFZFUlRJU0VEXzEwYmFzZVRfSGFsZjsKQEAgLTIzMDYsMjEgKzIz MDksMjEgQEAKIAlpZiAodG1wICYgQk1DUl9BTkVOQUJMRSkgewogCQllY21k LT5hZHZlcnRpc2luZyB8PSBBRFZFUlRJU0VEX0F1dG9uZWc7CiAJCWVjbWQt PmF1dG9uZWcgPSBBVVRPTkVHX0VOQUJMRTsKKwkJCisJCXRtcCA9IG1paV9u d2F5X3Jlc3VsdCgKKwkJCW5wLT5hZHZlcnRpc2luZyAmIG1kaW9fcmVhZChk ZXYsIDEsIE1JSV9MUEEpKTsKKwkJaWYgKHRtcCA9PSBMUEFfMTAwRlVMTCB8 fCB0bXAgPT0gTFBBXzEwMEhBTEYpCisJCQllY21kLT5zcGVlZCAgPSBTUEVF RF8xMDA7CisJCWVsc2UKKwkJCWVjbWQtPnNwZWVkICA9IFNQRUVEXzEwOwor CQlpZiAodG1wID09IExQQV8xMDBGVUxMIHx8IHRtcCA9PSBMUEFfMTBGVUxM KQorCQkJZWNtZC0+ZHVwbGV4ID0gRFVQTEVYX0ZVTEw7CisJCWVsc2UKKwkJ CWVjbWQtPmR1cGxleCA9IERVUExFWF9IQUxGOwogCX0gZWxzZSB7CiAJCWVj bWQtPmF1dG9uZWcgPSBBVVRPTkVHX0RJU0FCTEU7Ci0JfQotCi0JdG1wID0g cmVhZGwoZGV2LT5iYXNlX2FkZHIgKyBDaGlwQ29uZmlnKTsKLQlpZiAodG1w ICYgQ2ZnU3BlZWQxMDApIHsKLQkJZWNtZC0+c3BlZWQgPSBTUEVFRF8xMDA7 Ci0JfSBlbHNlIHsKLQkJZWNtZC0+c3BlZWQgPSBTUEVFRF8xMDsKLQl9Ci0K LQlpZiAodG1wICYgQ2ZnRnVsbER1cGxleCkgewotCQllY21kLT5kdXBsZXgg PSBEVVBMRVhfRlVMTDsKLQl9IGVsc2UgewotCQllY21kLT5kdXBsZXggPSBE VVBMRVhfSEFMRjsKKwkJZWNtZC0+c3BlZWQgICA9ICh0bXAgJiBCTUNSX1NQ RUVEMTAwKSA/IFNQRUVEXzEwMCAgIDogU1BFRURfMTA7CisJCWVjbWQtPmR1 cGxleCAgPSAodG1wICYgQk1DUl9GVUxMRFBMWCkgPyBEVVBMRVhfRlVMTCA6 IERVUExFWF9IQUxGOwogCX0KIAogCS8qIGlnbm9yZSBtYXh0eHBrdCwgbWF4 cnhwa3QgZm9yIG5vdyAqLwpAQCAtMjMzNywyMSArMjM0MCw2NCBAQAogCQly ZXR1cm4gLUVJTlZBTDsKIAlpZiAoZWNtZC0+ZHVwbGV4ICE9IERVUExFWF9I QUxGICYmIGVjbWQtPmR1cGxleCAhPSBEVVBMRVhfRlVMTCkKIAkJcmV0dXJu IC1FSU5WQUw7Ci0JaWYgKGVjbWQtPnBvcnQgIT0gUE9SVF9UUCAmJiBlY21k LT5wb3J0ICE9IFBPUlRfTUlJKQorCXN3aXRjaCAoZWNtZC0+cG9ydCkgewor CWNhc2UgUE9SVF9UUDoKKwkJaWYgKGRldi0+aWZfcG9ydCAhPSBQT1JUX1RQ KQorCQkJZWNtZC0+dHJhbnNjZWl2ZXIgPSBYQ1ZSX0lOVEVSTkFMOworCQll bHNlIGlmIChlY21kLT50cmFuc2NlaXZlciA9PSBYQ1ZSX0VYVEVSTkFMKQor CQkJZWNtZC0+cG9ydCA9IFBPUlRfTUlJOworCQlicmVhazsKKwljYXNlIFBP UlRfTUlJOgorCQlpZiAoZGV2LT5pZl9wb3J0ID09IFBPUlRfVFApCisJCQll Y21kLT50cmFuc2NlaXZlciA9IFhDVlJfRVhURVJOQUw7CisJCWVsc2UgaWYg KGVjbWQtPnRyYW5zY2VpdmVyID09IFhDVlJfSU5URVJOQUwpCisJCQllY21k LT5wb3J0ID0gUE9SVF9UUDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKIAkJcmV0 dXJuIC1FSU5WQUw7Ci0JaWYgKGVjbWQtPnRyYW5zY2VpdmVyICE9IFhDVlJf SU5URVJOQUwpCisJfQorCXRtcCA9IHJlYWRsKGRldi0+YmFzZV9hZGRyICsg Q2hpcENvbmZpZyk7CisJc3dpdGNoIChlY21kLT50cmFuc2NlaXZlcikgewor CWNhc2UgWENWUl9JTlRFUk5BTDoKKwkJdG1wICY9IH4oQ2ZnRXh0UGh5IHwg Q2ZnUGh5RGlzKTsKKwkJYnJlYWs7CisJY2FzZSBYQ1ZSX0VYVEVSTkFMOgor CQl0bXAgfD0gKENmZ0V4dFBoeSB8IENmZ1BoeURpcyk7CisJCWJyZWFrOwor CWRlZmF1bHQ6CiAJCXJldHVybiAtRUlOVkFMOworCX0KIAlpZiAoZWNtZC0+ YXV0b25lZyAhPSBBVVRPTkVHX0RJU0FCTEUgJiYgZWNtZC0+YXV0b25lZyAh PSBBVVRPTkVHX0VOQUJMRSkKIAkJcmV0dXJuIC1FSU5WQUw7Ci0JLyogaWdu b3JlIHBoeV9hZGRyZXNzLCBtYXh0eHBrdCwgbWF4cnhwa3QgZm9yIG5vdyAq LworCS8qIGlnbm9yZSBtYXh0eHBrdCwgbWF4cnhwa3QgZm9yIG5vdyAqLwog CiAJLyogV0hFVyEgbm93IGxldHMgYmFuZyBzb21lIGJpdHMgKi8KIAorCXdy aXRlbCh0bXAsIGRldi0+YmFzZV9hZGRyICsgQ2hpcENvbmZpZyk7CisJbnAt PnBoeV9hZGRyX2V4dGVybmFsID0gZWNtZC0+cGh5X2FkZHJlc3MgJiBQaHlB ZGRyTWFzazsKKwlkZXYtPmlmX3BvcnQgPSBlY21kLT5wb3J0OworCiAJdG1w ID0gbWRpb19yZWFkKGRldiwgMSwgTUlJX0JNQ1IpOwogCWlmIChlY21kLT5h dXRvbmVnID09IEFVVE9ORUdfRU5BQkxFKSB7Ci0JCS8qIHR1cm4gb24gYXV0 b25lZ290aWF0aW9uICovCi0JCXRtcCB8PSBCTUNSX0FORU5BQkxFOworCQkv KiB0dXJuIG9uIGF1dG9uZWdvdGlhdGlvbiwgYW5kIGZvcmNlIGEgcmVuZWdv dGlhdGUgKi8KKwkJdG1wIHw9IChCTUNSX0FORU5BQkxFIHwgQk1DUl9BTlJF U1RBUlQpOworCQlpZiAoKGVjbWQtPmFkdmVydGlzaW5nICYgKEFEVkVSVElT RURfMTBiYXNlVF9IYWxmIHwKKwkJCQkJICBBRFZFUlRJU0VEXzEwYmFzZVRf RnVsbCB8CisJCQkJCSAgQURWRVJUSVNFRF8xMDBiYXNlVF9IYWxmIHwKKwkJ CQkJICBBRFZFUlRJU0VEXzEwMGJhc2VUX0Z1bGwpKSA9PSAwKQorCQkJcmV0 dXJuIC1FSU5WQUw7CisJCS8qIGFkdmVydGlzZSBvbmx5IHdoYXQgaGFzIGJl ZW4gcmVxdWVzdGVkICovCiAJCW5wLT5hZHZlcnRpc2luZyA9IG1kaW9fcmVh ZChkZXYsIDEsIE1JSV9BRFZFUlRJU0UpOworCQlucC0+YWR2ZXJ0aXNpbmcg Jj0gfihBRFZFUlRJU0VfQUxMIHwgQURWRVJUSVNFXzEwMEJBU0U0KTsKKwkJ aWYgKGVjbWQtPmFkdmVydGlzaW5nICYgQURWRVJUSVNFRF8xMGJhc2VUX0hh bGYpCisJCQlucC0+YWR2ZXJ0aXNpbmcgfD0gQURWRVJUSVNFXzEwSEFMRjsK KwkJaWYgKGVjbWQtPmFkdmVydGlzaW5nICYgQURWRVJUSVNFRF8xMGJhc2VU X0Z1bGwpCisJCQlucC0+YWR2ZXJ0aXNpbmcgfD0gQURWRVJUSVNFXzEwRlVM TDsKKwkJaWYgKGVjbWQtPmFkdmVydGlzaW5nICYgQURWRVJUSVNFRF8xMDBi YXNlVF9IYWxmKQorCQkJbnAtPmFkdmVydGlzaW5nIHw9IEFEVkVSVElTRV8x MDBIQUxGOworCQlpZiAoZWNtZC0+YWR2ZXJ0aXNpbmcgJiBBRFZFUlRJU0VE XzEwMGJhc2VUX0Z1bGwpCisJCQlucC0+YWR2ZXJ0aXNpbmcgfD0gQURWRVJU SVNFXzEwMEZVTEw7CisJCW1kaW9fd3JpdGUoZGV2LCAxLCBNSUlfQURWRVJU SVNFLCBucC0+YWR2ZXJ0aXNpbmcpOwogCX0gZWxzZSB7CiAJCS8qIHR1cm4g b2ZmIGF1dG8gbmVnb3RpYXRpb24sIHNldCBzcGVlZCBhbmQgZHVwbGV4aXR5 ICovCiAJCXRtcCAmPSB+KEJNQ1JfQU5FTkFCTEUgfCBCTUNSX1NQRUVEMTAw IHwgQk1DUl9GVUxMRFBMWCk7CkBAIC0yMzczLDExICsyNDE4LDE1IEBACiAJ dTMyIHJmY3I7CiAJdTMyICpyYnVmID0gKHUzMiAqKWJ1ZjsKIAotCS8qIHJl YWQgYWxsIG9mIHBhZ2UgMCBvZiByZWdpc3RlcnMgKi8KLQlmb3IgKGkgPSAw OyBpIDwgTkFUU0VNSV9QRzBfTlJFR1M7IGkrKykgeworCS8qIHJlYWQgbm9u LW1paSBwYWdlIDAgb2YgcmVnaXN0ZXJzICovCisJZm9yIChpID0gMDsgaSA8 IE5BVFNFTUlfUEcwX05SRUdTLzI7IGkrKykgewogCQlyYnVmW2ldID0gcmVh ZGwoZGV2LT5iYXNlX2FkZHIgKyBpKjQpOwogCX0KIAorCS8qIHJlYWQgY3Vy cmVudCBtaWkgcmVnaXN0ZXJzICovCisJZm9yIChpID0gTkFUU0VNSV9QRzBf TlJFR1MvMjsgaSA8IE5BVFNFTUlfUEcwX05SRUdTOyBpKyspCisJCXJidWZb aV0gPSBtZGlvX3JlYWQoZGV2LCAxLCBpICYgMHgxZik7CisKIAkvKiByZWFk IG9ubHkgdGhlICdtYWdpYycgcmVnaXN0ZXJzIGZyb20gcGFnZSAxICovCiAJ d3JpdGV3KDEsIGRldi0+YmFzZV9hZGRyICsgUEdTRUwpOwogCXJidWZbaSsr XSA9IHJlYWR3KGRldi0+YmFzZV9hZGRyICsgUE1EQ1NSKTsK --=====_1086378783491=_-- From Gary.Spiess@Intermec.com Fri Jun 4 12:56:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 12:56:48 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Jujgi017083 for ; Fri, 4 Jun 2004 12:56:45 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id OAA00423; Fri, 4 Jun 2004 14:56:33 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i54MvuKJ023548; Fri, 4 Jun 2004 17:57:56 -0500 Message-ID: <200406041456330453.0BC6681C@136.179.85.112> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 04 Jun 2004 14:56:33 -0500 From: "Gary N Spiess" To: netdev@oss.sgi.com Cc: manfred@colorfullife.com Subject: [PATCH] natsemi update 4/4 External Fibre phy Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_10863789934827=_" X-archive-position: 5612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 4160 Lines: 91 --=====_10863789934827=_ Content-Type: multipart/alternative; boundary="=====_10863789935436=_" --=====_10863789935436=_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Jeff, This is the fourth of a series of patches needed to support our product= using the DP83815. This patch adds support for our Fibre phy. Sorry, I don't know anything= about the phy hardware. I know the couple of phy bits that need to be= twiddled. Gary oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 --=====_10863789935436=_ Content-Type: text/html; charset="us-ascii" Jeff,

This is the fourth of a series of patches needed to support our product using the DP83815.

This patch adds support for our Fibre phy.  Sorry, I don't know anything about the phy hardware.  I know the couple of phy bits that need to be twiddled.

Gary

 oooooooooooooooooooooooooooooooooooooooooooooooooo
 Gary Spiess (Gary.Spiess@Intermec.com)
 MobileLan Wireless Products Group, Intermec Technology Corp
 voice: 319 369-3580  fax: 319 369-3804
--=====_10863789935436=_-- --=====_10863789934827=_ Content-Type: application/octet-stream; name="natsemi-2.6.6-4.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="natsemi-2.6.6-4.patch" LS0tIGxpbnV4LTIuNi42L2RyaXZlcnMvbmV0L25hdHNlbWkuYwkyMDA0LTA2 LTAzIDE1OjEwOjAwLjAwMDAwMDAwMCAtMDUwMAorKysgbGludXgvZHJpdmVy cy9uZXQvbmF0c2VtaS5jCTIwMDQtMDYtMDMgMTU6MTA6MTYuMDAwMDAwMDAw IC0wNTAwCkBAIC0zNTEsNiArMzUxLDEwIEBACiBOb25lIGNoYXJhY3Rlcmlz ZWQuCiAqLwogCisvKiBhZGQgYSBjb3VwbGUgb2YgTUlJIGRlZmluaXRpb25z IHNwZWNpZmljIHRvIGEgUE9SVF9GSUJSRSBpbXBsZW1lbnRhdGlvbiAqLwor I2RlZmluZSBNSUlfTUNUUkwJMHgxNQkvKiBtb2RlIGNvbnRyb2wgcmVnaXN0 ZXIgKi8KKyNkZWZpbmUgTUlJX0lOX0ZYX01PREUJMHgwMDAxCS8qIGZ1bGwg ZHVwbGV4ICovCisjZGVmaW5lIE1JSV9ESVNfU0NSTQkweDAwMDQJLyogZGlz YWJsZSBzY3JhbWJsZXIgKi8KIAogCiBlbnVtIHBjaXN0dWZmIHsKQEAgLTI0 MDMsNyArMjQwNyw3IEBACiAJZWNtZC0+c3VwcG9ydGVkID0KIAkJKFNVUFBP UlRFRF8xMGJhc2VUX0hhbGYgfCBTVVBQT1JURURfMTBiYXNlVF9GdWxsIHwK IAkJU1VQUE9SVEVEXzEwMGJhc2VUX0hhbGYgfCBTVVBQT1JURURfMTAwYmFz ZVRfRnVsbCB8Ci0JCVNVUFBPUlRFRF9BdXRvbmVnIHwgU1VQUE9SVEVEX1RQ IHwgU1VQUE9SVEVEX01JSSk7CisJCVNVUFBPUlRFRF9BdXRvbmVnIHwgU1VQ UE9SVEVEX1RQIHwgU1VQUE9SVEVEX01JSSB8IFNVUFBPUlRFRF9GSUJSRSk7 CiAKIAkvKiBSZXR1cm4gdGhlIHRyYW5zY2VpdmVyIHR5cGUgKi8KIAllY21k LT5wb3J0ID0gZGV2LT5pZl9wb3J0OwpAQCAtMjQxNyw2ICsyNDIxLDEwIEBA CiAJCWVjbWQtPmFkdmVydGlzaW5nID0gQURWRVJUSVNFRF9NSUk7CiAJCWVj bWQtPnRyYW5zY2VpdmVyID0gWENWUl9FWFRFUk5BTDsKIAkJYnJlYWs7CisJ Y2FzZSBQT1JUX0ZJQlJFOgorCQllY21kLT5hZHZlcnRpc2luZyA9IEFEVkVS VElTRURfRklCUkU7CisJCWVjbWQtPnRyYW5zY2VpdmVyID0gWENWUl9FWFRF Uk5BTDsKKwkJYnJlYWs7CiAJfQogCWVjbWQtPnBvcnQgPSBkZXYtPmlmX3Bv cnQ7CiAJZWNtZC0+cGh5X2FkZHJlc3MgPSBucC0+cGh5X2FkZHJfZXh0ZXJu YWw7CkBAIC0yNDczLDYgKzI0ODEsNyBAQAogCQllbHNlIGlmIChlY21kLT50 cmFuc2NlaXZlciA9PSBYQ1ZSX0VYVEVSTkFMKQogCQkJZWNtZC0+cG9ydCA9 IFBPUlRfVFA7CiAJCWJyZWFrOworCWNhc2UgUE9SVF9GSUJSRToKIAljYXNl IFBPUlRfTUlJOgogCQlpZiAoZGV2LT5pZl9wb3J0ID09IFBPUlRfVFApCiAJ CQllY21kLT50cmFuc2NlaXZlciA9IFhDVlJfRVhURVJOQUw7CkBAIC0yNTAz LDYgKzI1MTIsMTUgQEAKIAlucC0+cGh5X2FkZHJfZXh0ZXJuYWwgPSBlY21k LT5waHlfYWRkcmVzcyAmIFBoeUFkZHJNYXNrOwogCWRldi0+aWZfcG9ydCA9 IGVjbWQtPnBvcnQ7CiAKKwkvKiBmaWJyZSBtb2RlPyAqLworCXRtcCA9IDA7 CisJaWYgKGRldi0+aWZfcG9ydCA9PSBQT1JUX0ZJQlJFKSB7CisJCXRtcCB8 PSBNSUlfRElTX1NDUk07CisJCWlmIChlY21kLT5kdXBsZXggPT0gRFVQTEVY X0ZVTEwpCisJCQl0bXAgfD0gTUlJX0lOX0ZYX01PREU7CisJfQorCW1kaW9f d3JpdGUoZGV2LCAxLCBNSUlfTUNUUkwsIHRtcCk7CisKIAl0bXAgPSBtZGlv X3JlYWQoZGV2LCAxLCBNSUlfQk1DUik7CiAJaWYgKGVjbWQtPmF1dG9uZWcg PT0gQVVUT05FR19FTkFCTEUpIHsKIAkJLyogdHVybiBvbiBhdXRvbmVnb3Rp YXRpb24sIGFuZCBmb3JjZSBhIHJlbmVnb3RpYXRlICovCg== --=====_10863789934827=_-- From davem@redhat.com Fri Jun 4 14:02:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 14:02:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54L2Pgi022219 for ; Fri, 4 Jun 2004 14:02:25 -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 i54L2Li5009011; Fri, 4 Jun 2004 17:02: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 i54L2L031420; Fri, 4 Jun 2004 17:02:21 -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 i54L2A5j019723; Fri, 4 Jun 2004 17:02:11 -0400 Date: Fri, 4 Jun 2004 14:00:20 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: Broken? 2.6.6 + IP_ADD_SOURCE_MEMBERSHIP + SO_REUSEADDR Message-Id: <20040604140020.1f30bc7b.davem@redhat.com> In-Reply-To: <20040605.021411.55160771.yoshfuji@linux-ipv6.org> References: <20040604155423.GA5656@muffin> <20040605.015544.102223977.yoshfuji@linux-ipv6.org> <20040605.021411.55160771.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 i54L2Pgi022219 X-archive-position: 5613 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: 415 Lines: 11 On Sat, 05 Jun 2004 02:14:11 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20040605.015544.102223977.yoshfuji@linux-ipv6.org> (at Sat, 05 Jun 2004 01:55:44 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > > The following patch should fix the issue. Please try. > > And, here's a variant for 2.4. Both patches applied, thanks. From davem@redhat.com Fri Jun 4 14:16:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 14:16:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54LG7gi022917 for ; Fri, 4 Jun 2004 14:16:07 -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 i54LFxi5011790; Fri, 4 Jun 2004 17:15:59 -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 i54LFx002366; Fri, 4 Jun 2004 17:15:59 -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 i54LFnBl024562; Fri, 4 Jun 2004 17:15:49 -0400 Date: Fri, 4 Jun 2004 14:13:59 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [BK PATCH] 2.6 and 2.4 SCTP updates. Message-Id: <20040604141359.19511d4a.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5614 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: 311 Lines: 9 On Fri, 4 Jun 2004 11:44:12 -0700 (PDT) Sridhar Samudrala wrote: > Please do a > bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work & > bk pull http://linux-lksctp.bkbits.net/lksctp-2.4.work > to get the following bugfix csets to 2.6 and 2.4 SCTP. Pulled, thanks Sridhar. From davem@redhat.com Fri Jun 4 14:31:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 14:31:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54LVdgi023523 for ; Fri, 4 Jun 2004 14:31:39 -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 i54LVTi5014583; Fri, 4 Jun 2004 17:31:29 -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 i54LVT005708; Fri, 4 Jun 2004 17:31: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 i54LVInv029070; Fri, 4 Jun 2004 17:31:19 -0400 Date: Fri, 4 Jun 2004 14:29:28 -0700 From: "David S. Miller" To: "Wesley W. Terpstra" Cc: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Broken? 2.6.6 + IP_ADD_SOURCE_MEMBERSHIP + SO_REUSEADDR Message-Id: <20040604142928.0d9045ce.davem@redhat.com> In-Reply-To: <20040604212916.GA6683@muffin> References: <20040604155423.GA5656@muffin> <20040605.015544.102223977.yoshfuji@linux-ipv6.org> <20040604212916.GA6683@muffin> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5615 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: 200 Lines: 8 On Fri, 4 Jun 2004 23:29:16 +0200 "Wesley W. Terpstra" wrote: > I am amazed you fixed it so fast! > Will this make it into 2.6.7? Yes, and 2.4.27 hopefully as well. From shemminger@osdl.org Fri Jun 4 14:54:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 14:54:46 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Lsdgi024237 for ; Fri, 4 Jun 2004 14:54: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 i54LrXr21971; Fri, 4 Jun 2004 14:53:34 -0700 Date: Fri, 4 Jun 2004 14:53:33 -0700 From: Stephen Hemminger To: Jes Sorensen , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] fix oops from acenic ethtool Message-Id: <20040604145333.34d1600f@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: 5616 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: 9150 Lines: 326 Fix the following OOPS that happens when doing ifup on FC-2 with 2.6.7 in acenic and a security hole due to missing capable(NET_ADMIN), by replacing private ethtool handling with ethtool_ops. (Yes, Jes because of DEV_ETHTOOL_OPS define it will still work on ancient kernels.) --------------------------------- # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/04 14:31:06-07:00 shemminger@osdl.org # Fix an OOPS and security hole by using ethtool_ops in acenic. # # drivers/net/acenic.h # 2004/06/04 14:30:56-07:00 shemminger@osdl.org +0 -1 # Fix an OOPS and security hole by using ethtool_ops in acenic. # # drivers/net/acenic.c # 2004/06/04 14:30:56-07:00 shemminger@osdl.org +127 -121 # Fix an OOPS and security hole by using ethtool_ops in acenic. # diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-06-04 14:31:46 -07:00 +++ b/drivers/net/acenic.c 2004-06-04 14:31:46 -07:00 @@ -443,6 +443,18 @@ "acenic.c: v0.92 08/05/2002 Jes Sorensen, linux-acenic@SunSITE.dk\n" " http://home.cern.ch/~jes/gige/acenic.html\n"; +#ifdef SET_ETHTOOL_OPS +static int ace_get_settings(struct net_device *, struct ethtool_cmd *); +static int ace_set_settings(struct net_device *, struct ethtool_cmd *); +static void ace_get_drvinfo(struct net_device *, struct ethtool_drvinfo *); + +static struct ethtool_ops ace_ethtool_ops = { + .get_settings = ace_get_settings, + .set_settings = ace_set_settings, + .get_drvinfo = ace_get_drvinfo, +}; +#endif + static int __devinit acenic_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) { @@ -480,7 +492,9 @@ dev->hard_start_xmit = &ace_start_xmit; dev->get_stats = &ace_get_stats; dev->set_multicast_list = &ace_set_multicast_list; - dev->do_ioctl = &ace_ioctl; +#ifdef SET_ETHTOOL_OPS + SET_ETHTOOL_OPS(dev, &ace_ethtool_ops); +#endif dev->set_mac_address = &ace_set_mac_addr; dev->change_mtu = &ace_change_mtu; @@ -2688,146 +2702,138 @@ return 0; } - -static int ace_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +#ifdef SET_ETHTOOL_OPS +static int ace_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { struct ace_private *ap = dev->priv; struct ace_regs *regs = ap->regs; -#ifdef SIOCETHTOOL - struct ethtool_cmd ecmd; - u32 link, speed; + u32 link; - if (cmd != SIOCETHTOOL) - return -EOPNOTSUPP; - if (copy_from_user(&ecmd, ifr->ifr_data, sizeof(ecmd))) - return -EFAULT; - switch (ecmd.cmd) { - case ETHTOOL_GSET: - ecmd.supported = - (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | - SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | - SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full | - SUPPORTED_Autoneg | SUPPORTED_FIBRE); - - ecmd.port = PORT_FIBRE; - ecmd.transceiver = XCVR_INTERNAL; - ecmd.phy_address = 0; - - link = readl(®s->GigLnkState); - if (link & LNK_1000MB) - ecmd.speed = SPEED_1000; - else { - link = readl(®s->FastLnkState); - if (link & LNK_100MB) - ecmd.speed = SPEED_100; - else if (link & LNK_100MB) - ecmd.speed = SPEED_10; - else - ecmd.speed = 0; - } - if (link & LNK_FULL_DUPLEX) - ecmd.duplex = DUPLEX_FULL; + memset(ecmd, 0, sizeof(struct ethtool_cmd)); + ecmd->supported = + (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full | + SUPPORTED_Autoneg | SUPPORTED_FIBRE); + + ecmd->port = PORT_FIBRE; + ecmd->transceiver = XCVR_INTERNAL; + + link = readl(®s->GigLnkState); + if (link & LNK_1000MB) + ecmd->speed = SPEED_1000; + else { + link = readl(®s->FastLnkState); + if (link & LNK_100MB) + ecmd->speed = SPEED_100; + else if (link & LNK_100MB) + ecmd->speed = SPEED_10; else - ecmd.duplex = DUPLEX_HALF; + ecmd->speed = 0; + } + if (link & LNK_FULL_DUPLEX) + ecmd->duplex = DUPLEX_FULL; + else + ecmd->duplex = DUPLEX_HALF; - if (link & LNK_NEGOTIATE) - ecmd.autoneg = AUTONEG_ENABLE; - else - ecmd.autoneg = AUTONEG_DISABLE; + if (link & LNK_NEGOTIATE) + ecmd->autoneg = AUTONEG_ENABLE; + else + ecmd->autoneg = AUTONEG_DISABLE; #if 0 - /* - * Current struct ethtool_cmd is insufficient - */ - ecmd.trace = readl(®s->TuneTrace); + /* + * Current struct ethtool_cmd is insufficient + */ + ecmd->trace = readl(®s->TuneTrace); - ecmd.txcoal = readl(®s->TuneTxCoalTicks); - ecmd.rxcoal = readl(®s->TuneRxCoalTicks); + ecmd->txcoal = readl(®s->TuneTxCoalTicks); + ecmd->rxcoal = readl(®s->TuneRxCoalTicks); #endif - ecmd.maxtxpkt = readl(®s->TuneMaxTxDesc); - ecmd.maxrxpkt = readl(®s->TuneMaxRxDesc); + ecmd->maxtxpkt = readl(®s->TuneMaxTxDesc); + ecmd->maxrxpkt = readl(®s->TuneMaxRxDesc); - if(copy_to_user(ifr->ifr_data, &ecmd, sizeof(ecmd))) - return -EFAULT; - return 0; - - case ETHTOOL_SSET: - link = readl(®s->GigLnkState); - if (link & LNK_1000MB) - speed = SPEED_1000; - else { - link = readl(®s->FastLnkState); - if (link & LNK_100MB) - speed = SPEED_100; - else if (link & LNK_100MB) - speed = SPEED_10; - else - speed = SPEED_100; - } + return 0; +} - link = LNK_ENABLE | LNK_1000MB | LNK_100MB | LNK_10MB | - LNK_RX_FLOW_CTL_Y | LNK_NEG_FCTL; - if (!ACE_IS_TIGON_I(ap)) - link |= LNK_TX_FLOW_CTL_Y; - if (ecmd.autoneg == AUTONEG_ENABLE) - link |= LNK_NEGOTIATE; - if (ecmd.speed != speed) { - link &= ~(LNK_1000MB | LNK_100MB | LNK_10MB); - switch (speed) { - case SPEED_1000: - link |= LNK_1000MB; - break; - case SPEED_100: - link |= LNK_100MB; - break; - case SPEED_10: - link |= LNK_10MB; - break; - } +static int ace_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd) +{ + struct ace_private *ap = dev->priv; + struct ace_regs *regs = ap->regs; + u32 link, speed; + + link = readl(®s->GigLnkState); + if (link & LNK_1000MB) + speed = SPEED_1000; + else { + link = readl(®s->FastLnkState); + if (link & LNK_100MB) + speed = SPEED_100; + else if (link & LNK_100MB) + speed = SPEED_10; + else + speed = SPEED_100; + } + + link = LNK_ENABLE | LNK_1000MB | LNK_100MB | LNK_10MB | + LNK_RX_FLOW_CTL_Y | LNK_NEG_FCTL; + if (!ACE_IS_TIGON_I(ap)) + link |= LNK_TX_FLOW_CTL_Y; + if (ecmd->autoneg == AUTONEG_ENABLE) + link |= LNK_NEGOTIATE; + if (ecmd->speed != speed) { + link &= ~(LNK_1000MB | LNK_100MB | LNK_10MB); + switch (speed) { + case SPEED_1000: + link |= LNK_1000MB; + break; + case SPEED_100: + link |= LNK_100MB; + break; + case SPEED_10: + link |= LNK_10MB; + break; } - if (ecmd.duplex == DUPLEX_FULL) - link |= LNK_FULL_DUPLEX; + } - if (link != ap->link) { - struct cmd cmd; - printk(KERN_INFO "%s: Renegotiating link state\n", - dev->name); + if (ecmd->duplex == DUPLEX_FULL) + link |= LNK_FULL_DUPLEX; - ap->link = link; - writel(link, ®s->TuneLink); - if (!ACE_IS_TIGON_I(ap)) - writel(link, ®s->TuneFastLink); - wmb(); + if (link != ap->link) { + struct cmd cmd; + printk(KERN_INFO "%s: Renegotiating link state\n", + dev->name); - cmd.evt = C_LNK_NEGOTIATION; - cmd.code = 0; - cmd.idx = 0; - ace_issue_cmd(regs, &cmd); - } - return 0; + ap->link = link; + writel(link, ®s->TuneLink); + if (!ACE_IS_TIGON_I(ap)) + writel(link, ®s->TuneFastLink); + wmb(); - case ETHTOOL_GDRVINFO: { - struct ethtool_drvinfo info = {ETHTOOL_GDRVINFO}; - strncpy(info.driver, "acenic", sizeof(info.driver) - 1); - sprintf(info.fw_version, "%i.%i.%i", - tigonFwReleaseMajor, tigonFwReleaseMinor, - tigonFwReleaseFix); - strncpy(info.version, version, sizeof(info.version) - 1); - if (ap && ap->pdev) - strcpy(info.bus_info, pci_name(ap->pdev)); - if (copy_to_user(ifr->ifr_data, &info, sizeof(info))) - return -EFAULT; - return 0; - } - default: - break; + cmd.evt = C_LNK_NEGOTIATION; + cmd.code = 0; + cmd.idx = 0; + ace_issue_cmd(regs, &cmd); } - -#endif - - return -EOPNOTSUPP; + return 0; } +static void ace_get_drvinfo(struct net_device *dev, + struct ethtool_drvinfo *info) +{ + struct ace_private *ap = dev->priv; + + strlcpy(info->driver, "acenic", sizeof(info->driver)); + snprintf(info->version, sizeof(info->version), "%i.%i.%i", + tigonFwReleaseMajor, tigonFwReleaseMinor, + tigonFwReleaseFix); + + if (ap->pdev) + strlcpy(info->bus_info, pci_name(ap->pdev), + sizeof(info->bus_info)); + +} +#endif /* * Set the hardware MAC address. diff -Nru a/drivers/net/acenic.h b/drivers/net/acenic.h --- a/drivers/net/acenic.h 2004-06-04 14:31:46 -07:00 +++ b/drivers/net/acenic.h 2004-06-04 14:31:46 -07:00 @@ -790,7 +790,6 @@ static void ace_dump_trace(struct ace_private *ap); static void ace_set_multicast_list(struct net_device *dev); static int ace_change_mtu(struct net_device *dev, int new_mtu); -static int ace_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd); static int ace_set_mac_addr(struct net_device *dev, void *p); static void ace_set_rxtx_parms(struct net_device *dev, int jumbo); static int ace_allocate_descriptors(struct net_device *dev); From terpstra@dvs1.informatik.tu-darmstadt.de Fri Jun 4 14:58:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 14:58:16 -0700 (PDT) Received: from paris.dvs1.informatik.tu-darmstadt.de (paris.dvs1.informatik.tu-darmstadt.de [130.83.166.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Lw0gi024593 for ; Fri, 4 Jun 2004 14:58:03 -0700 Received: by paris.dvs1.informatik.tu-darmstadt.de (Postfix, from userid 11060) id F27B58068D; Fri, 4 Jun 2004 23:29:14 +0200 (CEST) Date: Fri, 4 Jun 2004 23:29:16 +0200 From: "Wesley W. Terpstra" To: YOSHIFUJI Hideaki / =?utf-8?B?5ZCJ6Jek6Iux5piO?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: Broken? 2.6.6 + IP_ADD_SOURCE_MEMBERSHIP + SO_REUSEADDR Message-ID: <20040604212916.GA6683@muffin> References: <20040604155423.GA5656@muffin> <20040605.015544.102223977.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20040605.015544.102223977.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i54Lw0gi024593 X-archive-position: 5617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: terpstra@gkec.tu-darmstadt.de Precedence: bulk X-list: netdev Content-Length: 1318 Lines: 36 On Sat, Jun 05, 2004 at 01:55:44AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <20040604155423.GA5656@muffin> (at Fri, 4 Jun 2004 17:54:23 +0200), "Wesley W. Terpstra" says: > > If I launch the same program twice with different senders, the first program > > ceases to receive multicast packets. (Neither from its own sender, nor the > > second program's sender) The second program receives packets from its > > designated sender only (as expected). > > > > If both programs specify the same sender, then both programs receive the > > message (as expected). > > Thanks for the report. > The following patch should fix the issue. Please try. > Thanks again. > > ===== net/ipv4/udp.c 1.60 vs edited ===== > --- 1.60/net/ipv4/udp.c 2004-05-31 03:57:26 +09:00 > +++ edited/net/ipv4/udp.c 2004-06-05 01:47:07 +09:00 > @@ -294,7 +294,7 @@ > ipv6_only_sock(s) || > (s->sk_bound_dev_if && s->sk_bound_dev_if != dif)) > continue; > - if (!ip_mc_sf_allow(sk, loc_addr, rmt_addr, dif)) > + if (!ip_mc_sf_allow(s, loc_addr, rmt_addr, dif)) > continue; > goto found; > } That works. I have confirmed that multiple senders for multiple processes is fixed. I am amazed you fixed it so fast! Will this make it into 2.6.7? -- Wesley W. Terpstra From shemminger@osdl.org Fri Jun 4 15:38:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 15:38:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Mc2gi026245 for ; Fri, 4 Jun 2004 15:38: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 i54Mbnr29586; Fri, 4 Jun 2004 15:37:49 -0700 Date: Fri, 4 Jun 2004 15:37:49 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] common code for generating tcp_info Message-Id: <20040604153749.5d8a13b9@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: 5618 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: 6129 Lines: 189 There are two places tcp_diag (netlink) and getsockopt, both with almost the same code to generate tcp_info from the current socket state. Patch agains 2.6.7-rc2 Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c 2004-06-04 15:35:55 -07:00 +++ b/net/ipv4/tcp.c 2004-06-04 15:35:55 -07:00 @@ -2498,56 +2498,11 @@ break; case TCP_INFO: { struct tcp_info info; - u32 now = tcp_time_stamp; if (get_user(len, optlen)) return -EFAULT; - info.tcpi_state = sk->sk_state; - info.tcpi_ca_state = tp->ca_state; - info.tcpi_retransmits = tp->retransmits; - info.tcpi_probes = tp->probes_out; - info.tcpi_backoff = tp->backoff; - info.tcpi_options = 0; - if (tp->tstamp_ok) - info.tcpi_options |= TCPI_OPT_TIMESTAMPS; - if (tp->sack_ok) - info.tcpi_options |= TCPI_OPT_SACK; - if (tp->wscale_ok) { - info.tcpi_options |= TCPI_OPT_WSCALE; - info.tcpi_snd_wscale = tp->snd_wscale; - info.tcpi_rcv_wscale = tp->rcv_wscale; - } else { - info.tcpi_snd_wscale = 0; - info.tcpi_rcv_wscale = 0; - } - 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_snd_mss = tp->mss_cache_std; - info.tcpi_rcv_mss = tp->ack.rcv_mss; - - info.tcpi_unacked = tp->packets_out; - info.tcpi_sacked = tp->sacked_out; - info.tcpi_lost = tp->lost_out; - info.tcpi_retrans = tp->retrans_out; - info.tcpi_fackets = tp->fackets_out; - - info.tcpi_last_data_sent = ((now - tp->lsndtime) * 1000) / HZ; - info.tcpi_last_ack_sent = 0; - info.tcpi_last_data_recv = ((now - - tp->ack.lrcvtime) * 1000) / HZ; - info.tcpi_last_ack_recv = ((now - tp->rcv_tstamp) * 1000) / HZ; - - 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_snd_ssthresh = tp->snd_ssthresh; - info.tcpi_snd_cwnd = tp->snd_cwnd; - info.tcpi_advmss = tp->advmss; - info.tcpi_reordering = tp->reordering; + tcp_get_info(sk, &info); len = min_t(unsigned int, len, sizeof(info)); if (put_user(len, optlen)) diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c 2004-06-04 15:35:55 -07:00 +++ b/net/ipv4/tcp_diag.c 2004-06-04 15:35:55 -07:00 @@ -41,6 +41,58 @@ rta->rta_len = rtalen; \ RTA_DATA(rta); }) +/* Return information about state of tcp endpoint in API format. */ +void tcp_get_info(struct sock *sk, struct tcp_info *info) +{ + struct tcp_opt *tp = tcp_sk(sk); + u32 now = tcp_time_stamp; + + memset(info, 0, sizeof(*info)); + + info->tcpi_state = sk->sk_state; + info->tcpi_ca_state = tp->ca_state; + info->tcpi_retransmits = tp->retransmits; + info->tcpi_probes = tp->probes_out; + info->tcpi_backoff = tp->backoff; + + if (tp->tstamp_ok) + info->tcpi_options |= TCPI_OPT_TIMESTAMPS; + if (tp->sack_ok) + info->tcpi_options |= TCPI_OPT_SACK; + if (tp->wscale_ok) { + info->tcpi_options |= TCPI_OPT_WSCALE; + info->tcpi_snd_wscale = tp->snd_wscale; + info->tcpi_rcv_wscale = tp->rcv_wscale; + } + + 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_snd_mss = tp->mss_cache; + info->tcpi_rcv_mss = tp->ack.rcv_mss; + + info->tcpi_unacked = tp->packets_out; + info->tcpi_sacked = tp->sacked_out; + info->tcpi_lost = tp->lost_out; + info->tcpi_retrans = tp->retrans_out; + info->tcpi_fackets = 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_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_snd_ssthresh = tp->snd_ssthresh; + info->tcpi_snd_cwnd = tp->snd_cwnd; + info->tcpi_advmss = tp->advmss; + info->tcpi_reordering = tp->reordering; +} + static int tcpdiag_fill(struct sk_buff *skb, struct sock *sk, int ext, u32 pid, u32 seq) { @@ -150,55 +202,8 @@ minfo->tcpdiag_tmem = atomic_read(&sk->sk_wmem_alloc); } - if (info) { - u32 now = tcp_time_stamp; - - info->tcpi_state = sk->sk_state; - info->tcpi_ca_state = tp->ca_state; - info->tcpi_retransmits = tp->retransmits; - info->tcpi_probes = tp->probes_out; - info->tcpi_backoff = tp->backoff; - info->tcpi_options = 0; - if (tp->tstamp_ok) - info->tcpi_options |= TCPI_OPT_TIMESTAMPS; - if (tp->sack_ok) - info->tcpi_options |= TCPI_OPT_SACK; - if (tp->wscale_ok) { - info->tcpi_options |= TCPI_OPT_WSCALE; - info->tcpi_snd_wscale = tp->snd_wscale; - info->tcpi_rcv_wscale = tp->rcv_wscale; - } else { - info->tcpi_snd_wscale = 0; - info->tcpi_rcv_wscale = 0; - } - 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_snd_mss = tp->mss_cache; - info->tcpi_rcv_mss = tp->ack.rcv_mss; - - info->tcpi_unacked = tp->packets_out; - info->tcpi_sacked = tp->sacked_out; - info->tcpi_lost = tp->lost_out; - info->tcpi_retrans = tp->retrans_out; - info->tcpi_fackets = tp->fackets_out; - - info->tcpi_last_data_sent = ((now - tp->lsndtime)*1000)/HZ; - info->tcpi_last_ack_sent = 0; - info->tcpi_last_data_recv = ((now - tp->ack.lrcvtime)*1000)/HZ; - info->tcpi_last_ack_recv = ((now - tp->rcv_tstamp)*1000)/HZ; - - 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_snd_ssthresh = tp->snd_ssthresh; - info->tcpi_snd_cwnd = tp->snd_cwnd; - info->tcpi_advmss = tp->advmss; - info->tcpi_reordering = tp->reordering; - } + if (info) + tcp_get_info(sk, info); if (vinfo) { vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; From jmorris@redhat.com Fri Jun 4 16:56:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 16:56:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i54Nu5gi031013 for ; Fri, 4 Jun 2004 16:56:06 -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 i54Ntwi5009536; Fri, 4 Jun 2004 19:55:58 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i54Ntw006229; Fri, 4 Jun 2004 19:55:58 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i54NtvZE012274; Fri, 4 Jun 2004 19:55:57 -0400 Date: Fri, 4 Jun 2004 19:55:57 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: netfilter-devel@lists.netfilter.org cc: netdev@oss.sgi.com Subject: Developers please read: changes in Netfilter. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5619 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: 1088 Lines: 27 Netfilter developers should be aware of a changeset now merged into Linus' bk tree. A section of code in nf_hook_slow() which invalidates hardware checksums and recalculates them on output paths has been removed and pushed up to the Netfilter components which actually mangle packets (e.g. NAT). What this means is that any new code, or out of tree code (e.g. POM) needs to be reviewed to ensure that it handles hardware checksumming correctly itself, as the netfilter core code no longer does this. (Although note that NAT targets/helpers are covered automatically). Briefly, what needs to be done is: before mangling a packet in a way which might affect the TCP or UDP checksum, if the packet has hardware checksumming enabled, call skb_checksum_help(). For more details & code examples, refer to the changeset info: - James -- James Morris From davem@redhat.com Fri Jun 4 21:00:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 21:00:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55401gi006654 for ; Fri, 4 Jun 2004 21:00:02 -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 i553xui5019170; Fri, 4 Jun 2004 23:59:56 -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 i553xt015222; Fri, 4 Jun 2004 23:59:55 -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 i553xjo6017406; Fri, 4 Jun 2004 23:59:45 -0400 Date: Fri, 4 Jun 2004 20:57:49 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] common code for generating tcp_info Message-Id: <20040604205749.11725598.davem@redhat.com> In-Reply-To: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> References: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5620 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: 318 Lines: 10 On Fri, 4 Jun 2004 15:37:49 -0700 Stephen Hemminger wrote: > There are two places tcp_diag (netlink) and getsockopt, both with almost > the same code to generate tcp_info from the current socket state. Works for me, applied. Should maybe try to move that tcp_info off the stack at some point. From herbert@gondor.apana.org.au Fri Jun 4 22:29:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jun 2004 22:29:29 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i555TBgi009059 for ; Fri, 4 Jun 2004 22:29: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 1BWTie-0003ff-00; Sat, 05 Jun 2004 15:27:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BWTiT-00078P-00; Sat, 05 Jun 2004 15:27:37 +1000 Date: Sat, 5 Jun 2004 15:27:37 +1000 To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: 4/x: [NETDRV] Merge register_netdev calls Message-ID: <20040605052737.GA27406@gondor.apana.org.au> References: <20040313025859.GA8186@gondor.apana.org.au> <405C294D.5040508@pobox.com> <20040520111937.GA21804@gondor.apana.org.au> <20040522074435.GA9628@gondor.apana.org.au> <20040529084109.GA13032@gondor.apana.org.au> <40BE3778.1020404@pobox.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <40BE3778.1020404@pobox.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5621 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: 25402 Lines: 1057 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 02, 2004 at 04:24:24PM -0400, Jeff Garzik wrote: > > > >Here is the patch that adds register_ei_netdev which lets us get rid of > >some of the duplicated printk's in the 8390 drivers. > > Patch looks OK, but I would prefer to reject it, and merge it later when > an accompanying patch appears using this new function. Actually I've decided to scrap it in favour of a more generic ether_print_info() that can be used by all Ethernet drivers. So in its place I present the following patch that merges duplicate register_netdev calls by moving them to the probe function. 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 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/3c503.c 1.20 vs edited ===== --- 1.20/drivers/net/3c503.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/3c503.c 2004-06-05 14:05:23 +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.29 vs edited ===== --- 1.29/drivers/net/3c515.c 2004-03-30 20:17:59 +10:00 +++ edited/drivers/net/3c515.c 2004-06-05 15:16: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-22 17:28:45 +10:00 +++ edited/drivers/net/3c523.c 2004-06-05 14:12:44 +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-22 17:28:45 +10:00 +++ edited/drivers/net/ac3200.c 2004-06-05 14:39:11 +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.24 vs edited ===== --- 1.24/drivers/net/cs89x0.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/cs89x0.c 2004-06-05 14:20:36 +10:00 @@ -307,13 +307,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"); @@ -718,7 +712,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: @@ -1806,13 +1806,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-22 17:28:45 +10:00 +++ edited/drivers/net/e2100.c 2004-06-05 14:23:56 +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-22 17:28:45 +10:00 +++ edited/drivers/net/eepro.c 2004-06-05 14:23:09 +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.18 vs edited ===== --- 1.18/drivers/net/eexpress.c 2004-05-20 21:10:46 +10:00 +++ edited/drivers/net/eexpress.c 2004-06-05 14:27:54 +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-20 21:10:46 +10:00 +++ edited/drivers/net/es3210.c 2004-06-05 14:27:31 +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/eth16i.c 1.19 vs edited ===== --- 1.19/drivers/net/eth16i.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/eth16i.c 2004-06-05 14:28:57 +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.16 vs edited ===== --- 1.16/drivers/net/hp-plus.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/hp-plus.c 2004-06-05 14:29:37 +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/hp.c 1.14 vs edited ===== --- 1.14/drivers/net/hp.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/hp.c 2004-06-05 14:41:28 +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/hp100.c 1.28 vs edited ===== --- 1.28/drivers/net/hp100.c 2004-05-20 21:10:46 +10:00 +++ edited/drivers/net/hp100.c 2004-06-05 14:48:02 +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; @@ -2938,17 +2938,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); return err; @@ -3016,15 +3011,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/lance.c 1.22 vs edited ===== --- 1.22/drivers/net/lance.c 2004-05-20 21:10:47 +10:00 +++ edited/drivers/net/lance.c 2004-06-05 15:03:28 +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-27 18:57:44 +10:00 +++ edited/drivers/net/ne-h8300.c 2004-06-05 15:05:17 +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/isa-skeleton.c 1.13 vs edited ===== --- 1.13/drivers/net/isa-skeleton.c 2004-05-20 21:10:47 +10:00 +++ edited/drivers/net/isa-skeleton.c 2004-06-05 14:36:42 +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/lne390.c 1.14 vs edited ===== --- 1.14/drivers/net/lne390.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/lne390.c 2004-06-05 15:03:09 +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/ne.c 1.22 vs edited ===== --- 1.22/drivers/net/ne.c 2004-05-22 17:28:46 +10:00 +++ edited/drivers/net/ne.c 2004-06-05 15:06:46 +10:00 @@ -220,12 +220,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); @@ -506,8 +501,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; @@ -798,11 +799,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/ne2.c 1.16 vs edited ===== --- 1.16/drivers/net/ne2.c 2004-05-22 17:28:46 +10:00 +++ edited/drivers/net/ne2.c 2004-06-05 15:08:21 +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; @@ -800,11 +802,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/ne2k_cbus.c 1.7 vs edited ===== --- 1.7/drivers/net/ne2k_cbus.c 2004-05-22 17:28:46 +10:00 +++ edited/drivers/net/ne2k_cbus.c 2004-06-05 15:09:51 +10:00 @@ -204,12 +204,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); @@ -542,8 +537,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + ret = register_netdev(dev); + if (ret) + goto err_out_irq; return 0; +err_out_irq: + free_irq(dev->irq, dev); err_out_kfree: ne2k_cbus_destroy(dev); err_out: @@ -854,11 +855,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = hwtype[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/smc-ultra.c 1.22 vs edited ===== --- 1.22/drivers/net/smc-ultra.c 2004-05-22 17:28:46 +10:00 +++ edited/drivers/net/smc-ultra.c 2004-06-05 15:11:42 +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-22 17:28:46 +10:00 +++ edited/drivers/net/wd.c 2004-06-05 15:14:05 +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]); --y0ulUmNC+osPPQO6-- From herbert@gondor.apana.org.au Sat Jun 5 00:56:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 00:56:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i557uogi015168 for ; Sat, 5 Jun 2004 00:56: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 1BWW1W-0004Fn-00; Sat, 05 Jun 2004 17:55:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BWW1L-0007Tq-00; Sat, 05 Jun 2004 17:55:15 +1000 Date: Sat, 5 Jun 2004 17:55:15 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: [NETDRV] Fix netdev leak on probe failure in 3c527 Message-ID: <20040605075515.GA28723@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5622 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: 762 Lines: 33 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff: This patch frees the netdev on failure in mc32_probe in 3c527. 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 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/3c527.c 1.23 vs edited ===== --- 1.23/drivers/net/3c527.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/3c527.c 2004-06-05 17:51:23 +10:00 @@ -287,6 +287,7 @@ } } + free_netdev(dev); return ERR_PTR(-ENODEV); } --azLHFNyN32YCQGCU-- From rl@hellgate.ch Sat Jun 5 01:39:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 01:39:13 -0700 (PDT) Received: from mail3.bluewin.ch (mail3.bluewin.ch [195.186.1.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i558d5gi016126 for ; Sat, 5 Jun 2004 01:39:06 -0700 Received: from k3.hellgate.ch (83.77.24.119) by mail3.bluewin.ch (Bluewin AG 7.0.028) id 40A46963002627A2; Wed, 2 Jun 2004 11:58:50 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 887F18CA75E; Wed, 2 Jun 2004 13:58:50 +0200 (CEST) Date: Wed, 2 Jun 2004 13:58:50 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [6/9][PATCH 2.6] Return codes for rhine_init_one Message-ID: <20040602115850.GA17556@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602115703.GA16079@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 2660 Lines: 104 Use return codes in rhine_init_one instead of -ENODEV for all errors. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -616,7 +616,7 @@ { struct net_device *dev; struct rhine_private *rp; - int i, option; + int i, option, rc; int chip_id = (int) ent->driver_data; static int card_idx = -1; long ioaddr; @@ -638,11 +638,13 @@ option = card_idx < MAX_UNITS ? options[card_idx] : 0; io_size = rhine_chip_info[chip_id].io_size; - if (pci_enable_device(pdev)) + rc = pci_enable_device(pdev); + if (rc) goto err_out; /* this should always be supported */ - if (pci_set_dma_mask(pdev, 0xffffffff)) { + rc = pci_set_dma_mask(pdev, 0xffffffff); + if (rc) { printk(KERN_ERR "32-bit PCI DMA addresses not supported by " "the card!?\n"); goto err_out; @@ -651,6 +653,7 @@ /* sanity check */ if ((pci_resource_len(pdev, 0) < io_size) || (pci_resource_len(pdev, 1) < io_size)) { + rc = -EIO; printk(KERN_ERR "Insufficient PCI resources, aborting\n"); goto err_out; } @@ -662,6 +665,7 @@ dev = alloc_etherdev(sizeof(*rp)); if (dev == NULL) { + rc = -ENOMEM; printk(KERN_ERR "init_ethernet failed for card #%d\n", card_idx); goto err_out; @@ -669,7 +673,8 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - if (pci_request_regions(pdev, shortname)) + rc = pci_request_regions(pdev, shortname); + if (rc) goto err_out_free_netdev; #ifdef USE_MMIO @@ -678,6 +683,7 @@ ioaddr = (long) ioremap(memaddr, io_size); if (!ioaddr) { + rc = -EIO; printk(KERN_ERR "ioremap failed for device %s, region 0x%X " "@ 0x%lX\n", pci_name(pdev), io_size, memaddr); goto err_out_free_res; @@ -690,6 +696,7 @@ unsigned char a = inb(ioaddr0+reg); unsigned char b = readb(ioaddr+reg); if (a != b) { + rc = -EIO; printk(KERN_ERR "MMIO do not match PIO [%02x] " "(%02x != %02x)\n", reg, a, b); goto err_out_unmap; @@ -736,6 +743,7 @@ dev->dev_addr[i] = readb(ioaddr + StationAddr + i); if (!is_valid_ether_addr(dev->dev_addr)) { + rc = -EIO; printk(KERN_ERR "Invalid MAC address for card #%d\n", card_idx); goto err_out_unmap; } @@ -787,8 +795,8 @@ dev->features |= NETIF_F_SG|NETIF_F_HW_CSUM; /* dev->name not defined before register_netdev()! */ - i = register_netdev(dev); - if (i) + rc = register_netdev(dev); + if (rc) goto err_out_unmap; /* The lower four bits are the media type. */ @@ -871,7 +879,7 @@ err_out_free_netdev: free_netdev(dev); err_out: - return -ENODEV; + return rc; } static int alloc_ring(struct net_device* dev) From herbert@gondor.apana.org.au Sat Jun 5 01:40:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 01:40:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i558eLgi016265 for ; Sat, 5 Jun 2004 01:40: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 1BWWhM-0004ZK-00; Sat, 05 Jun 2004 18:38:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BWWhG-0007aN-00; Sat, 05 Jun 2004 18:38:34 +1000 Date: Sat, 5 Jun 2004 18:38:34 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: [NETDRV] Fixed MCA resource bugs in at1700 Message-ID: <20040605083834.GA29142@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5624 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: 67 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff: This patch fixes an incorrect MCA check as well as a leak on probe failure in at1700. 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 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/at1700.c 1.22 vs edited ===== --- 1.22/drivers/net/at1700.c 2004-05-22 17:28:45 +10:00 +++ edited/drivers/net/at1700.c 2004-06-05 18:34:29 +10:00 @@ -244,7 +244,7 @@ { #ifdef CONFIG_MCA struct net_local *lp = netdev_priv(dev); - if (lp->mca_slot) + if (lp->mca_slot >= 0) mca_mark_as_unused(lp->mca_slot); #endif free_irq(dev->irq, NULL); @@ -446,11 +446,11 @@ break; } if (i == 8) { - goto err_out; + goto err_mca; } } else { if (fmv18x_probe_list[inb(ioaddr + IOCONFIG) & 0x07] != ioaddr) - goto err_out; + goto err_mca; irq = fmv_irqmap[(inb(ioaddr + IOCONFIG)>>6) & 0x03]; } } @@ -548,11 +548,16 @@ if (ret) { printk (" AT1700 at %#3x is unusable due to a conflict on" "IRQ %d.\n", ioaddr, irq); - goto err_out; + goto err_mca; } return 0; +err_mca: +#ifdef CONFIG_MCA + if (slot >= 0) + mca_mark_as_unused(slot); +#endif err_out: #ifndef CONFIG_X86_PC9800 release_region(ioaddr, AT1700_IO_EXTENT); --a8Wt8u1KmwUX3Y2C-- From margitsw@t-online.de Sat Jun 5 03:51:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:51:18 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Ap9gi020691 for ; Sat, 5 Jun 2004 03:51:10 -0700 Received: from fwd04.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1BWYlA-0002kp-00; Sat, 05 Jun 2004 12:50:44 +0200 Received: from roglap.local (GEB2BsZZ8esVZlZnMJFL3Dm-VwozaHuI8gZfunk5cyAV5FNrKuiXEK@[217.224.28.133]) by fwd04.sul.t-online.com with esmtp id 1BWYks-0F6aZs0; Sat, 5 Jun 2004 12:50:26 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 6/17 linux-2.6.7-rc2] prism54: Kernel compatibility (resend) Date: Sat, 5 Jun 2004 14:48:08 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_IEcwA9i+0zpj2K4" Message-Id: <200406051448.08292.margitsw@t-online.de> X-Seen: false X-ID: GEB2BsZZ8esVZlZnMJFL3Dm-VwozaHuI8gZfunk5cyAV5FNrKuiXEK X-archive-position: 5625 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: 18948 Lines: 608 --Boundary-00=_IEcwA9i+0zpj2K4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-03-20 Margit Schubert-While * isl_38xx.[ch], isl_ioctl.c, islpci_dev.[ch], islpci_eth.c islpci_hotplug.c, islpci_mgt.[ch], oid_mgt.c, prismcompat.h: Adopt new prism54 kernel compatibility. Remove remaining kernel version ifdefs. --Boundary-00=_IEcwA9i+0zpj2K4 Content-Type: text/x-diff; charset="us-ascii"; name="06-kernel-compatibility.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="06-kernel-compatibility.patch" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/isl_38xx.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_38xx.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_38xx.c 2004-06-05 13:39:20.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_38xx.c 2004-06-05 13:45:32.000000000 +0200 @@ -25,17 +25,11 @@ #include #include -#include "isl_38xx.h" -#include - #include #include -#include -#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) -#error No Firmware Loading configured in the kernel ! -#endif - +#include "prismcompat.h" +#include "isl_38xx.h" #include "islpci_dev.h" #include "islpci_mgt.h" @@ -236,130 +230,6 @@ } int -isl38xx_upload_firmware(char *fw_id, _REQ_FW_DEV_T dev, void *device_base, - dma_addr_t host_address) -{ - u32 reg, rc; - -#if VERBOSE > SHOW_ERROR_MESSAGES - DEBUG(SHOW_ERROR_MESSAGES, "isl38xx_upload_firmware(0x%lx, 0x%lx)\n", - (long) device_base, (long) host_address); -#endif - - /* clear the RAMBoot and the Reset bit */ - reg = readl(device_base + ISL38XX_CTRL_STAT_REG); - reg &= ~ISL38XX_CTRL_STAT_RESET; - reg &= ~ISL38XX_CTRL_STAT_RAMBOOT; - writel(reg, device_base + ISL38XX_CTRL_STAT_REG); - wmb(); - udelay(ISL38XX_WRITEIO_DELAY); - - /* set the Reset bit without reading the register ! */ - reg |= ISL38XX_CTRL_STAT_RESET; - writel(reg, device_base + ISL38XX_CTRL_STAT_REG); - wmb(); - udelay(ISL38XX_WRITEIO_DELAY); - - /* clear the Reset bit */ - reg &= ~ISL38XX_CTRL_STAT_RESET; - writel(reg, device_base + ISL38XX_CTRL_STAT_REG); - wmb(); - - /* wait a while for the device to reboot */ - mdelay(50); - - { - const struct firmware *fw_entry = 0; - long fw_len; - const u32 *fw_ptr; - - rc = request_firmware(&fw_entry, fw_id, dev); - if (rc) { - printk(KERN_ERR - "%s: request_firmware() failed for '%s'\n", - "prism54", fw_id); - return rc; - } - /* prepare the Direct Memory Base register */ - reg = ISL38XX_DEV_FIRMWARE_ADDRES; - - fw_ptr = (u32 *) fw_entry->data; - fw_len = fw_entry->size; - - if (fw_len % 4) { - printk(KERN_ERR - "%s: firmware '%s' size is not multiple of 32bit, aborting!\n", - "prism54", fw_id); - release_firmware(fw_entry); - return EILSEQ; /* Illegal byte sequence */; - } - - while (fw_len > 0) { - long _fw_len = - (fw_len > - ISL38XX_MEMORY_WINDOW_SIZE) ? - ISL38XX_MEMORY_WINDOW_SIZE : fw_len; - u32 *dev_fw_ptr = device_base + ISL38XX_DIRECT_MEM_WIN; - - /* set the cards base address for writting the data */ - isl38xx_w32_flush(device_base, reg, - ISL38XX_DIR_MEM_BASE_REG); - wmb(); /* be paranoid */ - - /* increment the write address for next iteration */ - reg += _fw_len; - fw_len -= _fw_len; - - /* write the data to the Direct Memory Window 32bit-wise */ - /* memcpy_toio() doesn't guarantee 32bit writes :-| */ - while (_fw_len > 0) { - /* use non-swapping writel() */ - __raw_writel(*fw_ptr, dev_fw_ptr); - fw_ptr++, dev_fw_ptr++; - _fw_len -= 4; - } - - /* flush PCI posting */ - (void) readl(device_base + ISL38XX_PCI_POSTING_FLUSH); - wmb(); /* be paranoid again */ - - BUG_ON(_fw_len != 0); - } - - BUG_ON(fw_len != 0); - - release_firmware(fw_entry); - } - - /* now reset the device - * clear the Reset & ClkRun bit, set the RAMBoot bit */ - reg = readl(device_base + ISL38XX_CTRL_STAT_REG); - reg &= ~ISL38XX_CTRL_STAT_CLKRUN; - reg &= ~ISL38XX_CTRL_STAT_RESET; - reg |= ISL38XX_CTRL_STAT_RAMBOOT; - isl38xx_w32_flush(device_base, reg, ISL38XX_CTRL_STAT_REG); - wmb(); - udelay(ISL38XX_WRITEIO_DELAY); - - /* set the reset bit latches the host override and RAMBoot bits - * into the device for operation when the reset bit is reset */ - reg |= ISL38XX_CTRL_STAT_RESET; - writel(reg, device_base + ISL38XX_CTRL_STAT_REG); - /* don't do flush PCI posting here! */ - wmb(); - udelay(ISL38XX_WRITEIO_DELAY); - - /* clear the reset bit should start the whole circus */ - reg &= ~ISL38XX_CTRL_STAT_RESET; - writel(reg, device_base + ISL38XX_CTRL_STAT_REG); - /* don't do flush PCI posting here! */ - wmb(); - udelay(ISL38XX_WRITEIO_DELAY); - - return 0; -} - -int isl38xx_in_queue(isl38xx_control_block *cb, int queue) { const s32 delta = (le32_to_cpu(cb->driver_curr_frag[queue]) - diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/isl_38xx.h linux-2.6.6-01/drivers/net/wireless/prism54/isl_38xx.h --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_38xx.h 2004-06-05 13:39:20.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_38xx.h 2004-06-05 13:45:32.000000000 +0200 @@ -22,14 +22,6 @@ #include #include - -#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75)) -#include -# define _REQ_FW_DEV_T struct device * -#else -# define _REQ_FW_DEV_T char * -#endif - #include #define ISL38XX_CB_RX_QSIZE 8 @@ -174,6 +166,4 @@ void isl38xx_trigger_device(int, void *); void isl38xx_interface_reset(void *, dma_addr_t); -int isl38xx_upload_firmware(char *, _REQ_FW_DEV_T, void *, dma_addr_t); - #endif /* _ISL_38XX_H */ diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-05 13:39:34.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-05 13:44:14.000000000 +0200 @@ -25,10 +25,10 @@ #include #include #include -#include #include +#include "prismcompat.h" #include "isl_ioctl.h" #include "islpci_mgt.h" #include "isl_oid.h" /* additional types and defs for isl38xx fw */ diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.c 2004-06-05 13:39:34.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.c 2004-06-05 13:45:32.000000000 +0200 @@ -30,6 +30,7 @@ #include +#include "prismcompat.h" #include "isl_38xx.h" #include "isl_ioctl.h" #include "islpci_dev.h" @@ -37,12 +38,6 @@ #include "islpci_eth.h" #include "oid_mgt.h" -#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,5,0) -#define prism54_synchronize_irq(irq) synchronize_irq() -#else -#define prism54_synchronize_irq(irq) synchronize_irq(irq) -#endif - #define ISL3877_IMAGE_FILE "isl3877" #define ISL3890_IMAGE_FILE "isl3890" @@ -55,6 +50,125 @@ * ndev->set_mac_address. Jean II */ const unsigned char dummy_mac[6] = { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 }; +static int +isl_upload_firmware(islpci_private *priv) +{ + u32 reg, rc; + void *device_base = priv->device_base; + + /* clear the RAMBoot and the Reset bit */ + reg = readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &= ~ISL38XX_CTRL_STAT_RESET; + reg &= ~ISL38XX_CTRL_STAT_RAMBOOT; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the Reset bit without reading the register ! */ + reg |= ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &= ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reboot */ + mdelay(50); + + { + const struct firmware *fw_entry = 0; + long fw_len; + const u32 *fw_ptr; + + rc = request_firmware(&fw_entry, priv->firmware, PRISM_FW_PDEV); + if (rc) { + printk(KERN_ERR + "%s: request_firmware() failed for '%s'\n", + "prism54", priv->firmware); + return rc; + } + /* prepare the Direct Memory Base register */ + reg = ISL38XX_DEV_FIRMWARE_ADDRES; + + fw_ptr = (u32 *) fw_entry->data; + fw_len = fw_entry->size; + + if (fw_len % 4) { + printk(KERN_ERR + "%s: firmware '%s' size is not multiple of 32bit, aborting!\n", + "prism54", priv->firmware); + release_firmware(fw_entry); + return EILSEQ; /* Illegal byte sequence */; + } + + while (fw_len > 0) { + long _fw_len = + (fw_len > + ISL38XX_MEMORY_WINDOW_SIZE) ? + ISL38XX_MEMORY_WINDOW_SIZE : fw_len; + u32 *dev_fw_ptr = device_base + ISL38XX_DIRECT_MEM_WIN; + + /* set the cards base address for writting the data */ + isl38xx_w32_flush(device_base, reg, + ISL38XX_DIR_MEM_BASE_REG); + wmb(); /* be paranoid */ + + /* increment the write address for next iteration */ + reg += _fw_len; + fw_len -= _fw_len; + + /* write the data to the Direct Memory Window 32bit-wise */ + /* memcpy_toio() doesn't guarantee 32bit writes :-| */ + while (_fw_len > 0) { + /* use non-swapping writel() */ + __raw_writel(*fw_ptr, dev_fw_ptr); + fw_ptr++, dev_fw_ptr++; + _fw_len -= 4; + } + + /* flush PCI posting */ + (void) readl(device_base + ISL38XX_PCI_POSTING_FLUSH); + wmb(); /* be paranoid again */ + + BUG_ON(_fw_len != 0); + } + + BUG_ON(fw_len != 0); + + release_firmware(fw_entry); + } + + /* now reset the device + * clear the Reset & ClkRun bit, set the RAMBoot bit */ + reg = readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &= ~ISL38XX_CTRL_STAT_CLKRUN; + reg &= ~ISL38XX_CTRL_STAT_RESET; + reg |= ISL38XX_CTRL_STAT_RAMBOOT; + isl38xx_w32_flush(device_base, reg, ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the reset bit latches the host override and RAMBoot bits + * into the device for operation when the reset bit is reset */ + reg |= ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the reset bit should start the whole circus */ + reg &= ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + return 0; +} + /****************************************************************************** Device Interrupt Handler ******************************************************************************/ @@ -324,14 +438,7 @@ printk(KERN_DEBUG "%s: uploading firmware...\n", priv->ndev->name); - rc = isl38xx_upload_firmware(priv->firmware, -#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75)) - &priv->pdev->dev, -#else - pci_name(priv->pdev), -#endif - priv->device_base, - priv->device_host_address); + rc = isl_upload_firmware(priv); if (rc) { /* error uploading the firmware */ printk(KERN_ERR "%s: could not upload firmware ('%s')\n", @@ -357,15 +464,8 @@ int result = -ETIME; int count; -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) - /* This is 2.6 specific, nicer, shorter, but not in 2.4 yet */ DEFINE_WAIT(wait); prepare_to_wait(&priv->reset_done, &wait, TASK_UNINTERRUPTIBLE); -#else - DECLARE_WAITQUEUE(wait, current); - set_current_state(TASK_UNINTERRUPTIBLE); - add_wait_queue(&priv->reset_done, &wait); -#endif /* now the last step is to reset the interface */ isl38xx_interface_reset(priv->device_base, priv->device_host_address); @@ -390,13 +490,7 @@ } -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) - /* 2.6 specific too */ finish_wait(&priv->reset_done, &wait); -#else - remove_wait_queue(&priv->reset_done, &wait); - set_current_state(TASK_RUNNING); -#endif if(result) return result; diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.h linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.h --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.h 2004-06-05 13:39:34.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.h 2004-06-05 13:44:14.000000000 +0200 @@ -29,20 +29,6 @@ #include #include -#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) -# include -#else -# include -# define work_struct tq_struct -# define INIT_WORK INIT_TQUEUE -# define schedule_work schedule_task -#endif - -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,23) -#define free_netdev(x) kfree(x) -#define pci_name(x) x->slot_name -#endif - #include "isl_38xx.h" #include "isl_oid.h" #include "islpci_mgt.h" @@ -210,12 +196,6 @@ #define ISLPCI_TX_TIMEOUT (2*HZ) -#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2,5,75)) -# define irqreturn_t void -# define IRQ_HANDLED -# define IRQ_NONE -#endif - irqreturn_t islpci_interrupt(int, void *, struct pt_regs *); int prism54_post_setup(islpci_private *, int); diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-06-05 13:39:34.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-06-05 13:44:14.000000000 +0200 @@ -26,6 +26,7 @@ #include #include +#include "prismcompat.h" #include "isl_38xx.h" #include "islpci_eth.h" #include "islpci_mgt.h" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_hotplug.c 2004-06-05 13:39:20.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-06-05 13:44:14.000000000 +0200 @@ -24,6 +24,7 @@ #include #include /* For __init, __exit */ +#include "prismcompat.h" #include "islpci_dev.h" #include "islpci_mgt.h" /* for pc_debug */ #include "isl_oid.h" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c 2004-06-05 13:39:20.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c 2004-06-05 13:44:14.000000000 +0200 @@ -22,12 +22,12 @@ #include #include #include -#include #include #include #include +#include "prismcompat.h" #include "isl_38xx.h" #include "islpci_mgt.h" #include "isl_oid.h" /* additional types and defs for isl38xx fw */ @@ -456,21 +456,12 @@ const long wait_cycle_jiffies = (ISL38XX_WAIT_CYCLE * 10 * HZ) / 1000; long timeout_left = ISL38XX_MAX_WAIT_CYCLES * wait_cycle_jiffies; int err; -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) DEFINE_WAIT(wait); -#else - DECLARE_WAITQUEUE(wait, current); -#endif if (down_interruptible(&priv->mgmt_sem)) return -ERESTARTSYS; -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) prepare_to_wait(&priv->mgmt_wqueue, &wait, TASK_UNINTERRUPTIBLE); -#else - set_current_state(TASK_UNINTERRUPTIBLE); - add_wait_queue(&priv->mgmt_wqueue, &wait); -#endif err = islpci_mgt_transmit(ndev, operation, oid, senddata, sendlen); if(err) goto out; @@ -499,12 +490,7 @@ /* TODO: we should reset the device here */ out: -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) finish_wait(&priv->mgmt_wqueue, &wait); -#else - remove_wait_queue(&priv->mgmt_wqueue, &wait); - set_current_state(TASK_RUNNING); -#endif up(&priv->mgmt_sem); return err; } diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.h linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.h 2004-06-05 13:39:20.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.h 2004-06-05 13:44:14.000000000 +0200 @@ -24,15 +24,6 @@ #include #include -#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) -# include -#else -# include -# define work_struct tq_struct -# define INIT_WORK INIT_TQUEUE -# define schedule_work schedule_task -#endif - /* * Function definitions */ diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c 2004-06-05 13:39:34.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c 2004-06-05 13:44:14.000000000 +0200 @@ -16,6 +16,7 @@ * */ +#include "prismcompat.h" #include "islpci_dev.h" #include "islpci_mgt.h" #include "isl_oid.h" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/prismcompat.h linux-2.6.6-01/drivers/net/wireless/prism54/prismcompat.h --- linux-2.6.6ct/drivers/net/wireless/prism54/prismcompat.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.6-01/drivers/net/wireless/prism54/prismcompat.h 2004-06-05 13:45:32.000000000 +0200 @@ -0,0 +1,46 @@ +/* + * (C) 2004 Margit Schubert-While + * + * 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 + * + * 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 + * + */ + +/* + * Compatibility header file to aid support of different kernel versions + */ + +#ifdef PRISM54_COMPAT24 +#include "prismcompat24.h" +#else /* PRISM54_COMPAT24 */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq(irq) + +#define PRISM_FW_PDEV &priv->pdev->dev + +#endif /* _PRISM_COMPAT_H */ +#endif /* PRISM54_COMPAT24 */ --Boundary-00=_IEcwA9i+0zpj2K4-- From margitsw@t-online.de Sat Jun 5 03:51:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:51:57 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Apsgi020829 for ; Sat, 5 Jun 2004 03:51:55 -0700 Received: from fwd08.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1BWYlg-0003d7-06; Sat, 05 Jun 2004 12:51:16 +0200 Received: from roglap.local (rXDLRcZVQeHIAw9Sf1PnNOPg6bobWHwtwBBoLg7n9goOfOqF+nQ-sO@[217.224.28.133]) by fwd08.sul.t-online.com with esmtp id 1BWYlX-0rq0ga0; Sat, 5 Jun 2004 12:51:07 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 7/17 linux-2.6.7-rc2] prism54: Fix endian patch (resend) Date: Sat, 5 Jun 2004 14:48:49 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_xEcwAn8+ZGAgS1T" Message-Id: <200406051448.49243.margitsw@t-online.de> X-Seen: false X-ID: rXDLRcZVQeHIAw9Sf1PnNOPg6bobWHwtwBBoLg7n9goOfOqF+nQ-sO X-archive-position: 5626 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: 2796 Lines: 73 --Boundary-00=_xEcwAn8+ZGAgS1T Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline * Split out patch islpci_eth.c : * Fix endian problem (bug 74/75 related) --Boundary-00=_xEcwAn8+ZGAgS1T Content-Type: text/x-diff; charset="us-ascii"; name="07-fix-endian.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="07-fix-endian.patch" diff -NaurEb linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 14:40:26.996454744 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 14:25:30.065808928 +0200 @@ -262,9 +262,9 @@ if (priv->ndev->type == ARPHRD_IEEE80211_PRISM) { struct avs_80211_1_header *avs; /* extract the relevant data from the header */ - u32 clock = hdr->clock; + u32 clock = le32_to_cpu(hdr->clock); u8 rate = hdr->rate; - u16 freq = be16_to_cpu(hdr->freq); + u16 freq = le16_to_cpu(hdr->freq); u8 rssi = hdr->rssi; skb_pull(*skb, sizeof (struct rfmon_header)); @@ -288,20 +288,20 @@ sizeof (struct avs_80211_1_header)); - avs->version = htonl(P80211CAPTURE_VERSION); - avs->length = htonl(sizeof (struct avs_80211_1_header)); - avs->mactime = __cpu_to_be64(clock); - avs->hosttime = __cpu_to_be64(jiffies); - avs->phytype = htonl(6); /*OFDM: 6 for (g), 8 for (a) */ - avs->channel = htonl(channel_of_freq(freq)); - avs->datarate = htonl(rate * 5); - avs->antenna = htonl(0); /*unknown */ - avs->priority = htonl(0); /*unknown */ - avs->ssi_type = htonl(2); /*2: dBm, 3: raw RSSI */ - avs->ssi_signal = htonl(rssi); - avs->ssi_noise = htonl(priv->local_iwstatistics.qual.noise); /*better than 'undefined', I assume */ - avs->preamble = htonl(0); /*unknown */ - avs->encoding = htonl(0); /*unknown */ + avs->version = cpu_to_be32(P80211CAPTURE_VERSION); + avs->length = cpu_to_be32(sizeof (struct avs_80211_1_header)); + avs->mactime = cpu_to_be64(le64_to_cpu(clock)); + avs->hosttime = cpu_to_be64(jiffies); + avs->phytype = cpu_to_be32(6); /*OFDM: 6 for (g), 8 for (a) */ + avs->channel = cpu_to_be32(channel_of_freq(freq)); + avs->datarate = cpu_to_be32(rate * 5); + avs->antenna = cpu_to_be32(0); /*unknown */ + avs->priority = cpu_to_be32(0); /*unknown */ + avs->ssi_type = cpu_to_be32(3); /*2: dBm, 3: raw RSSI */ + avs->ssi_signal = cpu_to_be32(rssi & 0x7f); + avs->ssi_noise = cpu_to_be32(priv->local_iwstatistics.qual.noise); /*better than 'undefined', I assume */ + avs->preamble = cpu_to_be32(0); /*unknown */ + avs->encoding = cpu_to_be32(0); /*unknown */ } else skb_pull(*skb, sizeof (struct rfmon_header)); --Boundary-00=_xEcwAn8+ZGAgS1T-- From margitsw@t-online.de Sat Jun 5 03:52:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:52:52 -0700 (PDT) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Aqigi021173 for ; Sat, 5 Jun 2004 03:52:45 -0700 Received: from fwd05.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1BWYmi-0001y6-05; Sat, 05 Jun 2004 12:52:20 +0200 Received: from roglap.local (G-LQeiZDQeeJpMWhQ+9AbO3aNyKCANWfOcS-C37MxmFoIX+-HtVDU3@[217.224.28.133]) by fwd05.sul.t-online.com with esmtp id 1BWYmb-1qOtW40; Sat, 5 Jun 2004 12:52:13 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 11/17 linux-2.6.7-rc2] prism54: Don't allow mib reads while unconfigured (resend) Date: Sat, 5 Jun 2004 14:49:55 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_zFcwAfFmTGrEPSo" Message-Id: <200406051449.55893.margitsw@t-online.de> X-Seen: false X-ID: G-LQeiZDQeeJpMWhQ+9AbO3aNyKCANWfOcS-C37MxmFoIX+-HtVDU3 X-archive-position: 5627 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: 10353 Lines: 312 --Boundary-00=_zFcwAfFmTGrEPSo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 004-04-17 Aurelien Alleaume * oid_mgt.c, isl_ioctl.c : Cleanup. Prevented real oid reading before the card is configured with mib values (might be related to bug #53). --Boundary-00=_zFcwAfFmTGrEPSo Content-Type: text/x-diff; charset="us-ascii"; name="11-prevent-oid-read-before-config.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="11-prevent-oid-read-before-config.patch" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-05 14:02:14.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-05 14:03:15.000000000 +0200 @@ -173,14 +173,6 @@ prism54_mib_mode_helper(priv, init_mode); } -void -prism54_mib_init_work(islpci_private *priv) -{ - down_write(&priv->mib_sem); - mgt_commit(priv); - up_write(&priv->mib_sem); -} - /* this will be executed outside of atomic context thanks to * schedule_work(), thus we can as well use sleeping semaphore * locking */ @@ -195,13 +187,6 @@ if (down_interruptible(&priv->stats_sem)) return; -/* missing stats are : - * iwstatistics.qual.updated - * iwstatistics.discard.nwid - * iwstatistics.discard.fragment - * iwstatistics.discard.misc - * iwstatistics.miss.beacon */ - /* Noise floor. * I'm not sure if the unit is dBm. * Note : If we are not connected, this value seems to be irrelevant. */ @@ -425,7 +410,6 @@ /* by default the card sets this to 20. */ sens = vwrq->disabled ? 20 : vwrq->value; - /* set the ed threshold. */ return mgt_set_request(priv, DOT11_OID_EDTHRESHOLD, 0, &sens); } @@ -712,7 +696,7 @@ /* 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 MAXBSS=24. Anyway 24 AP It is probably enough. + * if you change the value of IWMAX_BSS=24. */ rvalue |= mgt_get_request(priv, DOT11_OID_BSSLIST, 0, NULL, &r); bsslist = r.ptr; @@ -969,8 +953,6 @@ * small frame <=> smaller than the rts threshold * This is not really the behavior expected by the wireless tool but it seems * to be a common behavior in other drivers. - * - * It seems that playing with this tends to hang the card -> DISABLED */ static int @@ -1002,14 +984,13 @@ lifetime = vwrq->value / 1024; /* now set what is requested */ - - if (slimit != 0) + if (slimit) rvalue = mgt_set_request(priv, DOT11_OID_SHORTRETRIES, 0, &slimit); - if (llimit != 0) + if (llimit) rvalue |= mgt_set_request(priv, DOT11_OID_LONGRETRIES, 0, &llimit); - if (lifetime != 0) + if (lifetime) rvalue |= mgt_set_request(priv, DOT11_OID_MAXTXLIFETIME, 0, &lifetime); @@ -1261,11 +1242,6 @@ prism54_set_u32(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { - /* - u32 *i = (int *) extra; - int param = *i; - int u = *(i + 1); - */ u32 oid = uwrq[0], u = uwrq[1]; return mgt_set_request((islpci_private *) ndev->priv, oid, 0, &u); @@ -1836,9 +1812,7 @@ 0); break; - /* Note : the following should never happen since we don't run the card in - * extended mode. - * Note : "mlme" is actually a "struct obj_mlmeex *" here, but this + /* Note : "mlme" is actually a "struct obj_mlmeex *" here, but this * is backward compatible layout-wise with "struct obj_mlme". */ diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.h linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.h --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.h 2004-06-05 13:39:20.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.h 2004-06-05 14:03:15.000000000 +0200 @@ -30,7 +30,6 @@ #define SUPPORTED_WIRELESS_EXT 16 void prism54_mib_init(islpci_private *); -void prism54_mib_init_work(islpci_private *); struct iw_statistics *prism54_get_wireless_stats(struct net_device *); void prism54_update_stats(islpci_private *); diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.c 2004-06-05 13:58:59.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.c 2004-06-05 14:03:15.000000000 +0200 @@ -504,7 +504,9 @@ * the IRQ line until we know for sure the reset went through */ isl38xx_enable_common_interrupts(priv->device_base); - prism54_mib_init_work(priv); + down_write(&priv->mib_sem); + mgt_commit(priv); + up_write(&priv->mib_sem); islpci_set_state(priv, PRV_STATE_READY); diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c 2004-06-05 14:02:14.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c 2004-06-05 14:03:15.000000000 +0200 @@ -312,8 +312,9 @@ * size of a receive buffer. Thus, if this check * triggers, we likely have kernel heap corruption. */ if (frag_len > MGMT_FRAME_SIZE) { - printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\ -n", ndev->name, frag_len, frag_len); + printk(KERN_WARNING + "%s: Bogus packet size of %d (%#x).\n", + ndev->name, frag_len, frag_len); frag_len = MGMT_FRAME_SIZE; } @@ -488,7 +489,8 @@ } if (timeleft == 0) { printk(KERN_DEBUG - "%s: timeout waiting for mgmt response %lu, trigging device\n", + "%s: timeout waiting for mgmt response %lu, " + "triggering device\n", ndev->name, timeout_left); islpci_trigger(priv); } diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c 2004-06-05 14:02:14.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c 2004-06-05 14:03:15.000000000 +0200 @@ -446,7 +446,7 @@ if (cache) down_write(&priv->mib_sem); - if (islpci_get_state(priv) >= PRV_STATE_INIT) { + if (islpci_get_state(priv) >= PRV_STATE_READY) { ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, oid, _data, dlen, &response); if (!ret) { @@ -500,7 +500,7 @@ if (cache) down_read(&priv->mib_sem); - if (islpci_get_state(priv) >= PRV_STATE_INIT) { + if (islpci_get_state(priv) >= PRV_STATE_READY) { ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, oid, data, dlen, &response); if (ret || !response || @@ -539,7 +539,7 @@ if (reslen > isl_oid[n].size) printk(KERN_DEBUG "mgt_get_request(0x%x): received data length was bigger " - "than expected (%d > %d). Memory is probably corrupted... ", + "than expected (%d > %d). Memory is probably corrupted...", oid, reslen, isl_oid[n].size); return ret; @@ -622,12 +622,32 @@ OID_INL_OUTPUTPOWER, }; +/* update the MAC addr. */ +static int +mgt_update_addr(islpci_private *priv) +{ + struct islpci_mgmtframe *res; + int ret; + + ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + isl_oid[GEN_OID_MACADDRESS].oid, NULL, + isl_oid[GEN_OID_MACADDRESS].size, &res); + + if ((ret == 0) && res && (res->header->operation != PIMFOR_OP_ERROR)) + memcpy(priv->ndev->dev_addr, res->data, 6); + else + ret = -EIO; + if (res) + islpci_mgt_release(res); + + return ret; +} + void mgt_commit(islpci_private *priv) { int rvalue; u32 u; - union oid_res_t r; if (islpci_get_state(priv) < PRV_STATE_INIT) return; @@ -643,6 +663,7 @@ u = OID_INL_MODE; rvalue |= mgt_commit_list(priv, &u, 1); + rvalue |= mgt_update_addr(priv); if (rvalue) { /* some request have failed. The device might be in an @@ -650,14 +671,6 @@ printk(KERN_DEBUG "%s: mgt_commit has failed. Restart the " "device \n", priv->ndev->name); } - - /* update the MAC addr. As it's not cached, no lock will be acquired by - * the mgt_get_request - */ - mgt_get_request(priv, GEN_OID_MACADDRESS, 0, NULL, &r); - memcpy(priv->ndev->dev_addr, r.ptr, 6); - kfree(r.ptr); - } /* This will tell you if you are allowed to answer a mlme(ex) request .*/ @@ -710,8 +723,11 @@ case OID_TYPE_BSS:{ struct obj_bss *bss = r->ptr; return snprintf(str, PRIV_STR_SIZE, - "age=%u\nchannel=%u\n\ - capinfo=0x%X\nrates=0x%X\nbasic_rates=0x%X\n", bss->age, bss->channel, bss->capinfo, bss->rates, bss->basic_rates); + "age=%u\nchannel=%u\n" + "capinfo=0x%X\nrates=0x%X\n" + "basic_rates=0x%X\n", bss->age, + bss->channel, bss->capinfo, + bss->rates, bss->basic_rates); } break; case OID_TYPE_BSSLIST:{ @@ -720,7 +736,9 @@ k = snprintf(str, PRIV_STR_SIZE, "nr=%u\n", list->nr); for (i = 0; i < list->nr; i++) k += snprintf(str + k, PRIV_STR_SIZE - k, - "bss[%u] : \nage=%u\nchannel=%u\ncapinfo=0x%X\nrates=0x%X\nbasic_rates=0x%X\n", + "bss[%u] : \nage=%u\nchannel=%u\n" + "capinfo=0x%X\nrates=0x%X\n" + "basic_rates=0x%X\n", i, list->bsslist[i].age, list->bsslist[i].channel, list->bsslist[i].capinfo, @@ -742,16 +760,17 @@ break; case OID_TYPE_MLME:{ struct obj_mlme *mlme = r->ptr; - return snprintf(str, PRIV_STR_SIZE, "id=0x%X\nstate=0x%X\n\ - code=0x%X\n", mlme->id, mlme->state, - mlme->code); + return snprintf(str, PRIV_STR_SIZE, + "id=0x%X\nstate=0x%X\ncode=0x%X\n", + mlme->id, mlme->state, mlme->code); } break; case OID_TYPE_MLMEEX:{ struct obj_mlmeex *mlme = r->ptr; - return snprintf(str, PRIV_STR_SIZE, "id=0x%X\nstate=0x%X\n\ - code=0x%X\nsize=0x%X\n", mlme->id, mlme->state, - mlme->code, mlme->size); + return snprintf(str, PRIV_STR_SIZE, + "id=0x%X\nstate=0x%X\n" + "code=0x%X\nsize=0x%X\n", mlme->id, + mlme->state, mlme->code, mlme->size); } break; case OID_TYPE_SSID:{ --Boundary-00=_zFcwAfFmTGrEPSo-- From margitsw@t-online.de Sat Jun 5 03:52:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:53:02 -0700 (PDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Aqugi021304 for ; Sat, 5 Jun 2004 03:52:57 -0700 Received: from fwd10.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1BWYnE-0002oZ-05; Sat, 05 Jun 2004 12:52:52 +0200 Received: from roglap.local (TbWRPcZGYeDHnrIMZ3QH5eB0Z50tnbV2SDXpYx5oWIuR3+GGD15ec5@[217.224.28.133]) by fwd10.sul.t-online.com with esmtp id 1BWYnA-0898qG0; Sat, 5 Jun 2004 12:52:48 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 13/17 linux-2.6.7-rc2] prism54: Align skb patch (resend) Date: Sat, 5 Jun 2004 14:50:30 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_WGcwAoFrpsImxIG" Message-Id: <200406051450.30316.margitsw@t-online.de> X-Seen: false X-ID: TbWRPcZGYeDHnrIMZ3QH5eB0Z50tnbV2SDXpYx5oWIuR3+GGD15ec5 X-archive-position: 5628 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: 1613 Lines: 45 --Boundary-00=_WGcwAoFrpsImxIG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline * islpci_eth.c, islpci_dev.c : Align skb->data unconditonally after allocation. This would appear to improve RX rate --Boundary-00=_WGcwAoFrpsImxIG Content-Type: text/x-diff; charset="us-ascii"; name="13-align-skb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="13-align-skb.patch" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.c 2004-06-05 14:06:30.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.c 2004-06-05 14:09:41.000000000 +0200 @@ -676,6 +676,7 @@ skb = NULL; goto out_free; } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); /* add the new allocated sk_buff to the buffer array */ priv->data_low_rx[counter] = skb; diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-06-05 14:09:07.000000000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-06-05 14:09:41.000000000 +0200 @@ -440,6 +440,7 @@ DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n"); break; } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); /* store the new skb structure pointer */ index = index % ISL38XX_CB_RX_QSIZE; priv->data_low_rx[index] = skb; --Boundary-00=_WGcwAoFrpsImxIG-- From margitsw@t-online.de Sat Jun 5 03:53:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:53:43 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Ardgi021916 for ; Sat, 5 Jun 2004 03:53:40 -0700 Received: from fwd11.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1BWYm1-0005ET-08; Sat, 05 Jun 2004 12:51:37 +0200 Received: from roglap.local (GW5i5cZE8eQ5SP3E3l8lEyws784hMXva7YOE3e+50o5Ii+mQtmO+YO@[217.224.28.133]) by fwd11.sul.t-online.com with esmtp id 1BWYls-1DYK8W0; Sat, 5 Jun 2004 12:51:28 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 8/17 linux-2.6.7-rc2] prism54: Fix bugs 74/75 (resend) Date: Sat, 5 Jun 2004 14:49:10 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_GFcwAqf0vwOMgYR" Message-Id: <200406051449.10281.margitsw@t-online.de> X-Seen: false X-ID: GW5i5cZE8eQ5SP3E3l8lEyws784hMXva7YOE3e+50o5Ii+mQtmO+YO X-archive-position: 5629 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: 1639 Lines: 54 --Boundary-00=_GFcwAqf0vwOMgYR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-03-22 Aurelien Alleaume * oid_mgt.c, isl_ioctl.c : Minor bugfixes : #74 and #75. --Boundary-00=_GFcwAqf0vwOMgYR Content-Type: text/x-diff; charset="us-ascii"; name="08-fix-bug-74-75.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="08-fix-bug-74-75.patch" diff -NaurEb linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 14:40:26.990455656 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 14:43:00.926053888 +0200 @@ -1893,6 +1893,7 @@ struct net_device *ndev = frame->ndev; enum oid_num_t n = mgt_oidtonum(frame->header->oid); + if (n != OID_NUM_LAST) prism54_process_trap_helper(netdev_priv(ndev), n, frame->data); islpci_mgt_release(frame); } diff -NaurEb linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c 2004-05-28 14:40:27.001453984 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c 2004-05-28 14:43:00.929053432 +0200 @@ -688,13 +688,13 @@ { int i; - for (i = 0; i < OID_NUM_LAST - 1; i++) + for (i = 0; i < OID_NUM_LAST; i++) if (isl_oid[i].oid == oid) return i; printk(KERN_DEBUG "looking for an unknown oid 0x%x", oid); - return 0; + return OID_NUM_LAST; } int --Boundary-00=_GFcwAqf0vwOMgYR-- From margitsw@t-online.de Sat Jun 5 03:53:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:54:02 -0700 (PDT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Arvgi022067 for ; Sat, 5 Jun 2004 03:53:57 -0700 Received: from fwd04.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1BWYno-0005Dk-00; Sat, 05 Jun 2004 12:53:28 +0200 Received: from roglap.local (XRnN-sZf8e6myqMlrYE1g-ZdM4pXAv6IyxXUp0aHEQ853KjQy6gew1@[217.224.28.133]) by fwd04.sul.t-online.com with esmtp id 1BWYnl-0vz7Pk0; Sat, 5 Jun 2004 12:53:25 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 15/17 linux-2.6.7-rc2] prism54: Fix channel stats, bump version to 1.2 (resend) Date: Sat, 5 Jun 2004 14:51:07 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_7GcwAXNDN/WMQKP" Message-Id: <200406051451.07953.margitsw@t-online.de> X-Seen: false X-ID: XRnN-sZf8e6myqMlrYE1g-ZdM4pXAv6IyxXUp0aHEQ853KjQy6gew1 X-archive-position: 5630 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: 2909 Lines: 84 --Boundary-00=_7GcwAXNDN/WMQKP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-05-20 Aurelien Alleaume * islpci_eth.c : use dev_kfree_skb_irq instead of dev_kfree_skb where needed. * isl_ioctl.c : report channel instead of frequency in scan. * islpci_hotplug.c : bump version to 1.2 --Boundary-00=_7GcwAXNDN/WMQKP Content-Type: text/x-diff; charset="us-ascii"; name="15-fix-channel.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="15-fix-channel.patch" diff -NaurEbB linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 15:44:40.849580016 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 15:49:40.516023792 +0200 @@ -632,8 +629,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 = bss->channel; - iwe.u.freq.e = 6; + iwe.u.freq.m = channel_of_freq(bss->channel); + iwe.u.freq.e = 0; iwe.cmd = SIOCGIWFREQ; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); diff -NaurEbB linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 15:48:34.157111880 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 15:49:40.517023640 +0200 @@ -275,7 +275,7 @@ avs_80211_1_header), 0, GFP_ATOMIC); if (newskb) { - kfree_skb(*skb); + dev_kfree_skb_irq(*skb); *skb = newskb; } else return -1; @@ -419,7 +419,7 @@ skb->data[4], skb->data[5]); #endif if (unlikely(discard)) { - dev_kfree_skb(skb); + dev_kfree_skb_irq(skb); skb = NULL; } else netif_rx(skb); @@ -462,7 +462,7 @@ "Error mapping DMA address\n"); /* free the skbuf structure before aborting */ - dev_kfree_skb((struct sk_buff *) skb); + dev_kfree_skb_irq((struct sk_buff *) skb); skb = NULL; break; } diff -NaurEbB linux-2.6.6ct/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_hotplug.c 2004-05-28 14:40:26.997454592 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-05-28 15:49:40.519023336 +0200 @@ -30,7 +30,7 @@ #include "isl_oid.h" #define DRV_NAME "prism54" -#define DRV_VERSION "1.1" +#define DRV_VERSION "1.2" MODULE_AUTHOR("[Intersil] R.Bastings and W.Termorshuizen, The prism54.org Development Team "); MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter"); --Boundary-00=_7GcwAXNDN/WMQKP-- From margitsw@t-online.de Sat Jun 5 03:54:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:54:04 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55As0gi022101 for ; Sat, 5 Jun 2004 03:54:01 -0700 Received: from fwd02.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1BWYn3-00031L-01; Sat, 05 Jun 2004 12:52:41 +0200 Received: from roglap.local (SrY4+YZf8e2cV4TAAKoGeQBFloXx1WUOkTZ3ijqJvXuC8JvEf+Ozrr@[217.224.28.133]) by fwd02.sul.t-online.com with esmtp id 1BWYmo-1ld0tM0; Sat, 5 Jun 2004 12:52:26 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 12/17 linux-2.6.7-rc2] prism54: Add likely/unlikely, KO wds completely (resend) Date: Sat, 5 Jun 2004 14:50:08 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_AGcwArowYloYPgO" Message-Id: <200406051450.08650.margitsw@t-online.de> X-Seen: false X-ID: SrY4+YZf8e2cV4TAAKoGeQBFloXx1WUOkTZ3ijqJvXuC8JvEf+Ozrr X-archive-position: 5631 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: 4148 Lines: 106 --Boundary-00=_AGcwArowYloYPgO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline * islpci_mgt.h : Change init_wds definition * islpci_eth.c : Do some likely/unlikely --Boundary-00=_AGcwArowYloYPgO Content-Type: text/x-diff; charset="us-ascii"; name="12-add-likely.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="12-add-likely.patch" diff -NaurEbB linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 14:41:32.820447976 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 15:33:42.187711840 +0200 @@ -105,7 +105,7 @@ /* check whether the destination queue has enough fragments for the frame */ curr_frag = le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ]); - if (curr_frag - priv->free_data_tx >= ISL38XX_CB_TX_QSIZE) { + if (unlikely(curr_frag - priv->free_data_tx >= ISL38XX_CB_TX_QSIZE)) { printk(KERN_ERR "%s: transmit device queue full when awake\n", ndev->name); netif_stop_queue(ndev); @@ -121,7 +121,7 @@ /* Check alignment and WDS frame formatting. The start of the packet should * be aligned on a 4-byte boundary. If WDS is enabled add another 6 bytes * and add WDS address information */ - if (((long) skb->data & 0x03) | init_wds) { + if (unlikely(((long) skb->data & 0x03) | init_wds)) { /* get the number of bytes to add and re-allign */ offset = (4 - (long) skb->data) & 0x03; offset += init_wds ? 6 : 0; @@ -192,7 +192,7 @@ pci_map_address = pci_map_single(priv->pdev, (void *) skb->data, skb->len, PCI_DMA_TODEVICE); - if (pci_map_address == 0) { + if (unlikely(pci_map_address == 0)) { printk(KERN_WARNING "%s: cannot map buffer to PCI\n", ndev->name); @@ -382,10 +382,10 @@ skb->dev = ndev; /* take care of monitor mode and spy monitoring. */ - if (priv->iw_mode == IW_MODE_MONITOR) + if (unlikely(priv->iw_mode == IW_MODE_MONITOR)) discard = islpci_monitor_rx(priv, &skb); else { - if (skb->data[2 * ETH_ALEN] == 0) { + if (unlikely(skb->data[2 * ETH_ALEN] == 0)) { /* The packet has a rx_annex. Read it for spy monitoring, Then * remove it, while keeping the 2 leading MAC addr. */ @@ -418,7 +418,7 @@ skb->data[0], skb->data[1], skb->data[2], skb->data[3], skb->data[4], skb->data[5]); #endif - if (discard) { + if (unlikely(discard)) { dev_kfree_skb(skb); skb = NULL; } else @@ -434,7 +434,8 @@ index - priv->free_data_rx < ISL38XX_CB_RX_QSIZE) { /* allocate an sk_buff for received data frames storage * include any required allignment operations */ - if (skb = dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2), skb == NULL) { + skb = dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2); + if (unlikely(skb == NULL)) { /* error allocating an sk_buff structure elements */ DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n"); break; @@ -454,7 +455,7 @@ pci_map_single(priv->pdev, (void *) skb->data, MAX_FRAGMENT_SIZE_RX + 2, PCI_DMA_FROMDEVICE); - if (priv->pci_map_rx_address[index] == (dma_addr_t) NULL) { + if (unlikely(priv->pci_map_rx_address[index] == (dma_addr_t) NULL)) { /* error mapping the buffer to device accessable memory address */ DEBUG(SHOW_ERROR_MESSAGES, "Error mapping DMA address\n"); diff -NaurEbB linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.h linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.h 2004-05-28 14:40:27.000454136 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.h 2004-05-28 15:33:42.188711688 +0200 @@ -34,7 +34,7 @@ #define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> " __FUNCTION__ "()\n", devname) extern int pc_debug; -static const int init_wds = 0; /* help compiler optimize away dead code */ +const int init_wds = 0; /* help compiler optimize away dead code */ /* General driver definitions */ --Boundary-00=_AGcwArowYloYPgO-- From margitsw@t-online.de Sat Jun 5 03:54:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 03:54:19 -0700 (PDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55As7gi022233 for ; Sat, 5 Jun 2004 03:54:08 -0700 Received: from fwd03.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1BWYoO-00084d-03; Sat, 05 Jun 2004 12:54:04 +0200 Received: from roglap.local (ThyW5cZBYe4xnhtK+3vFhKP33xgYXDnNkYa6s8v6l6QBeixv-7FGrN@[217.224.28.133]) by fwd03.sul.t-online.com with esmtp id 1BWYoB-1Q9H280; Sat, 5 Jun 2004 12:53:51 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 17/17 linux-2.6.7-rc2] prism54: White space and indentation (resend) Date: Sat, 5 Jun 2004 14:51:34 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_WHcwAw8pWE41qOR" Message-Id: <200406051451.34065.margitsw@t-online.de> X-Seen: false X-ID: ThyW5cZBYe4xnhtK+3vFhKP33xgYXDnNkYa6s8v6l6QBeixv-7FGrN X-archive-position: 5632 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: 18402 Lines: 624 --Boundary-00=_WHcwAw8pWE41qOR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-05-29 Margit Schubert-While * White space and indentation patch --Boundary-00=_WHcwAw8pWE41qOR Content-Type: text/x-diff; charset="us-ascii"; name="17-white-space-indent.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="17-white-space-indent.patch" diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 15:50:41.989678376 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 15:49:40.516023792 +0200 @@ -166,7 +166,7 @@ * 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__); + "Using default mode\n", __FUNCTION__); init_mode = CARD_DEFAULT_IW_MODE; } /* This sets all of the mode-dependent values */ @@ -518,9 +518,7 @@ i++; data++; } - range->num_bitrates = i; - kfree(r.ptr); return rvalue; @@ -559,7 +557,6 @@ int rvalue; rvalue = mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); - memcpy(awrq->sa_data, r.ptr, 6); awrq->sa_family = ARPHRD_ETHER; kfree(r.ptr); @@ -669,7 +666,6 @@ kfree(buf); } } - return current_ev; } @@ -731,7 +727,7 @@ memcpy(essid.octets, extra, dwrq->length); } else essid.length = 0; - + if (priv->iw_mode != IW_MODE_MONITOR) return mgt_set_request(priv, DOT11_OID_SSID, 0, &essid); @@ -817,21 +813,21 @@ char *data; int ret, i; union oid_res_t r; - + if (vwrq->value == -1) { /* auto mode. No limit. */ profile = 1; return mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); } - + if ((ret = mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r))) return ret; - + rate = (u32) (vwrq->value / 500000); data = r.ptr; i = 0; - + while (data[i]) { if (rate && (data[i] == rate)) { break; @@ -842,14 +838,14 @@ data[i] |= 0x80; i++; } - + if (!data[i]) { return -EINVAL; } - + data[i] |= 0x80; data[i + 1] = 0; - + /* Now, check if we want a fixed or auto value */ if (vwrq->fixed) { data[0] = data[i]; @@ -864,14 +860,14 @@ i++; } printk("0\n"); -*/ +*/ profile = -1; ret = mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); ret |= mgt_set_request(priv, DOT11_OID_EXTENDEDRATES, 0, data); ret |= mgt_set_request(priv, DOT11_OID_RATES, 0, data); - + kfree(r.ptr); - + return ret; } @@ -897,7 +893,7 @@ data = r.ptr; vwrq->fixed = (data[0] != 0) && (data[1] == 0); kfree(r.ptr); - + return 0; } @@ -994,7 +990,6 @@ rvalue |= mgt_set_request(priv, DOT11_OID_MAXTXLIFETIME, 0, &lifetime); - return rvalue; } @@ -1090,8 +1085,7 @@ } } } - - /* now read the flags */ + /* now read the flags */ if (dwrq->flags & IW_ENCODE_DISABLED) { /* Encoding disabled, * authen = DOT11_AUTH_OS; @@ -1240,7 +1234,7 @@ static int prism54_set_u32(struct net_device *ndev, struct iw_request_info *info, - __u32 * uwrq, char *extra) + __u32 * uwrq, char *extra) { u32 oid = uwrq[0], u = uwrq[1]; @@ -1858,7 +1852,7 @@ enum oid_num_t n = mgt_oidtonum(frame->header->oid); if (n != OID_NUM_LAST) - prism54_process_trap_helper(netdev_priv(ndev), n, frame->data); + prism54_process_trap_helper(netdev_priv(ndev), n, frame->data); islpci_mgt_release(frame); } @@ -1935,7 +1929,7 @@ __u32 * uwrq, char *extra) { islpci_private *priv = netdev_priv(ndev); - + priv->priv_oid = *uwrq; printk("%s: oid 0x%08X\n", ndev->name, *uwrq); @@ -1944,15 +1938,15 @@ int prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *info, - struct iw_point *data, char *extra) + struct iw_point *data, char *extra) { islpci_private *priv = netdev_priv(ndev); struct islpci_mgmtframe *response = NULL; int ret = -EIO, response_op = PIMFOR_OP_ERROR; - + printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); data->length = 0; - + if (islpci_get_state(priv) >= PRV_STATE_INIT) { ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, @@ -1976,21 +1970,21 @@ printk("%s: len: %i\n", ndev->name, data->length); } } - + return ret; } int prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *info, - struct iw_point *data, char *extra) + struct iw_point *data, char *extra) { islpci_private *priv = netdev_priv(ndev); struct islpci_mgmtframe *response = NULL; int ret = 0, response_op = PIMFOR_OP_ERROR; - + printk("%s: set_oid 0x%08X\tlen: %d\n", ndev->name, priv->priv_oid, data->length); - + if (islpci_get_state(priv) >= PRV_STATE_INIT) { ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, @@ -2005,10 +1999,10 @@ } if (ret || response_op == PIMFOR_OP_ERROR) { printk("%s: EIO\n", ndev->name); - ret = -EIO; + ret = -EIO; } } - + return (ret ? ret : -EINPROGRESS); } @@ -2107,7 +2101,7 @@ #define PRISM54_DBG_GET_OID SIOCIWFIRSTPRIV+15 #define PRISM54_DBG_SET_OID SIOCIWFIRSTPRIV+16 -#define PRISM54_GET_OID SIOCIWFIRSTPRIV+17 +#define PRISM54_GET_OID SIOCIWFIRSTPRIV+17 #define PRISM54_SET_OID_U32 SIOCIWFIRSTPRIV+18 #define PRISM54_SET_OID_STR SIOCIWFIRSTPRIV+20 #define PRISM54_SET_OID_ADDR SIOCIWFIRSTPRIV+22 @@ -2179,7 +2173,7 @@ IWPRIV_U32(DOT11_OID_AUTHENABLE, "authenable"), IWPRIV_U32(DOT11_OID_PRIVACYINVOKED, "privinvok"), IWPRIV_U32(DOT11_OID_EXUNENCRYPTED, "exunencrypt"), - + IWPRIV_U32(DOT11_OID_REKEYTHRESHOLD, "rekeythresh"), IWPRIV_U32(DOT11_OID_MAXTXLIFETIME, "maxtxlife"), diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.h linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.h --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_dev.h 2004-05-28 14:40:26.994455048 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_dev.h 2004-05-28 14:25:30.063809232 +0200 @@ -173,7 +173,7 @@ islpci_state_t state; int state_off; /* enumeration of off-state, if 0 then * we're not in any off-state */ - + /* WPA stuff */ int wpa; /* WPA mode enabled */ struct list_head bss_wpa_list; diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 15:50:41.991678072 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 15:49:40.517023640 +0200 @@ -208,7 +208,7 @@ priv->data_low_tx[index] = skb; /* set the proper fragment start address and size information */ fragment->size = cpu_to_le16(frame_size); - fragment->flags = cpu_to_le16(0); /* set to 1 if more fragments */ + fragment->flags = cpu_to_le16(0); /* set to 1 if more fragments */ fragment->address = cpu_to_le32(pci_map_address); curr_frag++; @@ -218,7 +218,7 @@ cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ] = cpu_to_le32(curr_frag); if (curr_frag - priv->free_data_tx + ISL38XX_MIN_QTHRESHOLD - > ISL38XX_CB_TX_QSIZE) { + > ISL38XX_CB_TX_QSIZE) { /* stop sends from upper layers */ netif_stop_queue(ndev); @@ -239,7 +239,7 @@ return 0; - drop_free: + drop_free: /* free the skbuf structure before aborting */ dev_kfree_skb(skb); skb = NULL; @@ -287,7 +287,7 @@ (struct avs_80211_1_header *) skb_push(*skb, sizeof (struct avs_80211_1_header)); - + avs->version = cpu_to_be32(P80211CAPTURE_VERSION); avs->length = cpu_to_be32(sizeof (struct avs_80211_1_header)); avs->mactime = cpu_to_be64(le64_to_cpu(clock)); @@ -487,10 +487,10 @@ void islpci_do_reset_and_wake(void *data) { - islpci_private *priv = (islpci_private *) data; - islpci_reset(priv, 1); - netif_wake_queue(priv->ndev); - priv->reset_task_pending = 0; + islpci_private *priv = (islpci_private *) data; + islpci_reset(priv, 1); + netif_wake_queue(priv->ndev); + priv->reset_task_pending = 0; } void diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c 2004-05-28 15:14:49.426917656 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c 2004-05-28 15:12:49.370169056 +0200 @@ -85,7 +85,7 @@ { pimfor_header_t *h = data; - while ((void *) h < data + len) { + while ((void *) h < data + len) { if (h->flags & PIMFOR_FLAG_LITTLE_ENDIAN) { le32_to_cpus(&h->oid); le32_to_cpus(&h->length); @@ -107,8 +107,8 @@ islpci_mgmt_rx_fill(struct net_device *ndev) { islpci_private *priv = netdev_priv(ndev); - isl38xx_control_block *cb = /* volatile not needed */ - (isl38xx_control_block *) priv->control_block; + isl38xx_control_block *cb = /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; u32 curr = le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ]); #if VERBOSE > SHOW_ERROR_MESSAGES @@ -140,15 +140,15 @@ } } - /* be safe: always reset control block information */ + /* be safe: always reset control block information */ frag->size = cpu_to_le16(MGMT_FRAME_SIZE); frag->flags = 0; frag->address = cpu_to_le32(buf->pci_addr); curr++; - /* The fragment address in the control block must have - * been written before announcing the frame buffer to - * device */ + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ wmb(); cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] = cpu_to_le32(curr); } @@ -168,7 +168,7 @@ { islpci_private *priv = netdev_priv(ndev); isl38xx_control_block *cb = - (isl38xx_control_block *) priv->control_block; + (isl38xx_control_block *) priv->control_block; void *p; int err = -EINVAL; unsigned long flags; @@ -242,7 +242,7 @@ priv->mgmt_tx[index] = buf; frag = &cb->tx_data_mgmt[index]; frag->size = cpu_to_le16(frag_len); - frag->flags = 0; /* for any other than the last fragment, set to 1 */ + frag->flags = 0; /* for any other than the last fragment, set to 1 */ frag->address = cpu_to_le32(buf.pci_addr); /* The fragment address in the control block must have @@ -256,11 +256,11 @@ islpci_trigger(priv); return 0; - error_unlock: + error_unlock: spin_unlock_irqrestore(&priv->slock, flags); - error_free: + error_free: kfree(buf.mem); - error: + error: return err; } @@ -274,16 +274,16 @@ { islpci_private *priv = netdev_priv(ndev); isl38xx_control_block *cb = - (isl38xx_control_block *) priv->control_block; + (isl38xx_control_block *) priv->control_block; u32 curr_frag; #if VERBOSE > SHOW_ERROR_MESSAGES DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive \n"); #endif - /* Only once per interrupt, determine fragment range to - * process. This avoids an endless loop (i.e. lockup) if - * frames come in faster than we can process them. */ + /* Only once per interrupt, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * frames come in faster than we can process them. */ curr_frag = le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_RX_MGMTQ]); barrier(); @@ -294,29 +294,29 @@ u16 frag_len; int size; struct islpci_mgmtframe *frame; - - /* I have no idea (and no documentation) if flags != 0 - * is possible. Drop the frame, reuse the buffer. */ + + /* I have no idea (and no documentation) if flags != 0 + * is possible. Drop the frame, reuse the buffer. */ if (le16_to_cpu(cb->rx_data_mgmt[index].flags) != 0) { - printk(KERN_WARNING "%s: unknown flags 0x%04x\n", - ndev->name, - le16_to_cpu(cb->rx_data_mgmt[index].flags)); - continue; - } + printk(KERN_WARNING "%s: unknown flags 0x%04x\n", + ndev->name, + le16_to_cpu(cb->rx_data_mgmt[index].flags)); + continue; + } /* The device only returns the size of the header(s) here. */ frag_len = le16_to_cpu(cb->rx_data_mgmt[index].size); /* - * We appear to have no way to tell the device the - * size of a receive buffer. Thus, if this check - * triggers, we likely have kernel heap corruption. */ - if (frag_len > MGMT_FRAME_SIZE) { + * We appear to have no way to tell the device the + * size of a receive buffer. Thus, if this check + * triggers, we likely have kernel heap corruption. */ + if (frag_len > MGMT_FRAME_SIZE) { printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", ndev->name, frag_len, frag_len); - frag_len = MGMT_FRAME_SIZE; - } + frag_len = MGMT_FRAME_SIZE; + } /* Ensure the results of device DMA are visible to the CPU. */ pci_dma_sync_single(priv->pdev, buf->pci_addr, @@ -338,7 +338,7 @@ #if VERBOSE > SHOW_ERROR_MESSAGES DEBUG(SHOW_PIMFOR_FRAMES, "PIMFOR: op %i, oid 0x%08x, device %i, flags 0x%x length 0x%x \n", - header->operation, header->oid, header->device_id, + header->operation, header->oid, header->device_id, header->flags, header->length); /* display the buffer contents for debugging */ @@ -363,7 +363,7 @@ printk(KERN_WARNING "%s: Out of memory, cannot handle oid 0x%08x\n", ndev->name, header->oid); - continue; + continue; } frame->ndev = ndev; memcpy(&frame->buf, header, size); @@ -383,7 +383,7 @@ header->oid, header->device_id, header->flags, header->length); #endif - + /* Create work to handle trap out of interrupt * context. */ INIT_WORK(&frame->ws, prism54_process_trap, frame); @@ -416,19 +416,19 @@ islpci_mgt_cleanup_transmit(struct net_device *ndev) { islpci_private *priv = netdev_priv(ndev); - isl38xx_control_block *cb = /* volatile not needed */ - (isl38xx_control_block *) priv->control_block; + isl38xx_control_block *cb = /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; u32 curr_frag; #if VERBOSE > SHOW_ERROR_MESSAGES - DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_cleanup_transmit\n"); + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_cleanup_transmit\n"); #endif /* Only once per cleanup, determine fragment range to * process. This avoids an endless loop (i.e. lockup) if * the device became confused, incrementing device_curr_frag * rapidly. */ - curr_frag = le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_TX_MGMTQ]); + curr_frag = le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_TX_MGMTQ]); barrier(); for (; priv->index_mgmt_tx < curr_frag; priv->index_mgmt_tx++) { @@ -475,9 +475,9 @@ frame = xchg(&priv->mgmt_received, NULL); if (frame) { if (frame->header->oid == oid) { - *recvframe = frame; - err = 0; - goto out; + *recvframe = frame; + err = 0; + goto out; } else { printk(KERN_DEBUG "%s: expecting oid 0x%x, received 0x%x.\n", @@ -485,13 +485,13 @@ frame->header->oid); kfree(frame); frame = NULL; - } + } } if (timeleft == 0) { printk(KERN_DEBUG "%s: timeout waiting for mgmt response %lu, " "triggering device\n", - ndev->name, timeout_left); + ndev->name, timeout_left); islpci_trigger(priv); } timeout_left += timeleft - wait_cycle_jiffies; diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c 2004-05-28 15:14:49.431916896 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c 2004-05-28 15:12:49.372168752 +0200 @@ -454,7 +454,7 @@ islpci_mgt_release(response); } if (ret || response_op == PIMFOR_OP_ERROR) - ret = -EIO; + ret = -EIO; } else if (!cache) ret = -EIO; @@ -479,7 +479,7 @@ int ret = -EIO; int reslen = 0; struct islpci_mgmtframe *response = NULL; - + int dlen; void *cache, *_res = NULL; u32 oid; @@ -504,7 +504,7 @@ ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, oid, data, dlen, &response); if (ret || !response || - response->header->operation == PIMFOR_OP_ERROR) { + response->header->operation == PIMFOR_OP_ERROR) { if (response) islpci_mgt_release(response); ret = -EIO; @@ -541,7 +541,7 @@ "mgt_get_request(0x%x): received data length was bigger " "than expected (%d > %d). Memory is probably corrupted...", oid, reslen, isl_oid[n].size); - + return ret; } @@ -561,11 +561,11 @@ while (j <= t->range) { response = NULL; ret |= islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, - oid, data, t->size, + oid, data, t->size, &response); if (response) { ret |= (response->header->operation == - PIMFOR_OP_ERROR); + PIMFOR_OP_ERROR); islpci_mgt_release(response); } j++; @@ -669,7 +669,7 @@ /* 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); + "device \n", priv->ndev->name); } } diff -Naur linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.h linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.h --- linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.h 2004-05-28 14:07:22.645122000 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.h 2004-05-28 14:06:37.941917920 +0200 @@ -38,7 +38,7 @@ int mgt_set_request(islpci_private *, enum oid_num_t, int, void *); int mgt_get_request(islpci_private *, enum oid_num_t, int, void *, - union oid_res_t *); + union oid_res_t *); int mgt_commit_list(islpci_private *, enum oid_num_t *, int); --Boundary-00=_WHcwAw8pWE41qOR-- From hadi@znyx.com Sat Jun 5 04:22:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 04:22:52 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55BMdgi027008 for ; Sat, 5 Jun 2004 04:22:39 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004060504214840:11409 ; Sat, 5 Jun 2004 04:21:48 -0700 Subject: small netfilter cleanup From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Harald Welte Cc: netdev@oss.sgi.com, "David S. Miller" Organization: ZNYX Networks Message-Id: <1086434538.1590.16.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jun 2004 07:22:19 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/05/2004 04:21:49 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/05/2004 04:22:07 AM, Serialize complete at 06/05/2004 04:22:07 AM Content-Type: multipart/mixed; boundary="=-q0+k3WAQkq6HY9b92iVN" X-archive-position: 5633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 21299 Lines: 670 --=-q0+k3WAQkq6HY9b92iVN Content-Transfer-Encoding: 7bit Content-Type: text/plain I have been sitting on these patches for sometime now. Harald, we did discuss this back when. Attached patches for 2.4.26 and 2.6.6; both should patch cleanly against pre 2.4.27 and 2.6.7 cheers, jamal --=-q0+k3WAQkq6HY9b92iVN Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=nf24p Content-Type: text/plain; name=nf24p; charset=ISO-8859-1 --- /usr/src/2426/include/linux/netfilter.h 2003-08-25 07:44:44.000000000 -0400 +++ /usr/src/2426-mod/include/linux/netfilter.h 2004-06-03 22:51:00.000000000 -0400 @@ -146,6 +146,12 @@ struct nf_info *info, unsigned int verdict); +extern inline struct ipt_target * +ipt_find_target_lock(const char *name, int *error, struct semaphore *mutex); +extern inline struct ip6t_target * +ip6t_find_target_lock(const char *name, int *error, struct semaphore *mutex); +extern inline struct arpt_target * +arpt_find_target_lock(const char *name, int *error, struct semaphore *mutex); extern void (*ip_ct_attach)(struct sk_buff *, struct nf_ct_info *); #ifdef CONFIG_NETFILTER_DEBUG --- /usr/src/2426/include/linux/netfilter_ipv4/ip_tables.h 2002-02-25 14:38:13.000000000 -0500 +++ /usr/src/2426-mod/include/linux/netfilter_ipv4/ip_tables.h 2004-06-03 22:52:39.000000000 -0400 @@ -283,6 +283,8 @@ struct ipt_entry entrytable[0]; }; +extern struct semaphore ipt_mutex; + /* Standard return verdict, or do jump. */ #define IPT_STANDARD_TARGET "" /* Error verdict. */ @@ -334,6 +336,7 @@ /* * Main firewall chains definitions and global var's definitions. */ +static DECLARE_MUTEX(ipt_mutex); #ifdef __KERNEL__ #include @@ -403,6 +406,11 @@ struct module *me; }; +extern struct ipt_target * +ipt_find_target_lock(const char *name, int *error, struct semaphore *mutex); +extern struct arpt_target * +arpt_find_target_lock(const char *name, int *error, struct semaphore *mutex); + extern int ipt_register_target(struct ipt_target *target); extern void ipt_unregister_target(struct ipt_target *target); --- /usr/src/2426/net/ipv4/netfilter/ip_tables.c 2004-02-18 08:36:32.000000000 -0500 +++ /usr/src/2426-mod/net/ipv4/netfilter/ip_tables.c 2004-06-03 21:56:59.000000000 -0400 @@ -53,9 +53,6 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) -/* Mutex protects lists (only traversed in user context). */ -static DECLARE_MUTEX(ipt_mutex); - /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) #define ASSERT_WRITE_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) @@ -418,7 +415,7 @@ { void *ret; -#if 0 +#if 0 duprintf("find_inlist: searching for `%s' in %s.\n", name, head == &ipt_target ? "ipt_target" : head == &ipt_match ? "ipt_match" @@ -464,7 +461,7 @@ #endif static inline struct ipt_table * -find_table_lock(const char *name, int *error, struct semaphore *mutex) +ipt_find_table_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ipt_tables, name, "iptable_", error, mutex); } @@ -475,8 +472,8 @@ return find_inlist_lock(&ipt_match, name, "ipt_", error, mutex); } -static inline struct ipt_target * -find_target_lock(const char *name, int *error, struct semaphore *mutex) +struct ipt_target * +ipt_find_target_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ipt_target, name, "ipt_", error, mutex); } @@ -693,7 +690,7 @@ goto cleanup_matches; t = ipt_get_target(e); - target = find_target_lock(t->u.user.name, &ret, &ipt_mutex); + target = ipt_find_target_lock(t->u.user.name, &ret, &ipt_mutex); if (!target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); goto cleanup_matches; @@ -1030,7 +1027,7 @@ int ret; struct ipt_table *t; - t = find_table_lock(entries->name, &ret, &ipt_mutex); + t = ipt_find_table_lock(entries->name, &ret, &ipt_mutex); if (t) { duprintf("t->private->number = %u\n", t->private->number); @@ -1097,7 +1094,7 @@ duprintf("ip_tables: Translated table\n"); - t = find_table_lock(tmp.name, &ret, &ipt_mutex); + t = ipt_find_table_lock(tmp.name, &ret, &ipt_mutex); if (!t) goto free_newinfo_counters_untrans; @@ -1191,7 +1188,7 @@ goto free; } - t = find_table_lock(tmp.name, &ret, &ipt_mutex); + t = ipt_find_table_lock(tmp.name, &ret, &ipt_mutex); if (!t) goto free; @@ -1266,7 +1263,7 @@ break; } name[IPT_TABLE_MAXNAMELEN-1] = '\0'; - t = find_table_lock(name, &ret, &ipt_mutex); + t = ipt_find_table_lock(name, &ret, &ipt_mutex); if (t) { struct ipt_getinfo info; @@ -1838,6 +1835,7 @@ EXPORT_SYMBOL(ipt_do_table); EXPORT_SYMBOL(ipt_register_target); EXPORT_SYMBOL(ipt_unregister_target); +EXPORT_SYMBOL(ipt_find_target_lock); module_init(init); module_exit(fini); --- /usr/src/2426/include/linux/netfilter_arp.h 2002-08-02 20:39:45.000000000 -0400 +++ /usr/src/2426-mod/include/linux/netfilter_arp.h 2004-06-03 22:52:11.000000000 -0400 @@ -16,4 +16,5 @@ #define NF_ARP_OUT 1 #define NF_ARP_NUMHOOKS 2 +static DECLARE_MUTEX(arpt_mutex); #endif /* __LINUX_ARP_NETFILTER_H */ --- /usr/src/2426/net/ipv4/netfilter/arp_tables.c 2003-08-25 07:44:44.000000000 -0400 +++ /usr/src/2426-mod/net/ipv4/netfilter/arp_tables.c 2004-06-03 21:56:59.000000000 -0400 @@ -52,7 +52,6 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) -static DECLARE_MUTEX(arpt_mutex); #define ASSERT_READ_LOCK(x) ARP_NF_ASSERT(down_trylock(&arpt_mutex) != 0) #define ASSERT_WRITE_LOCK(x) ARP_NF_ASSERT(down_trylock(&arpt_mutex) != 0) @@ -380,12 +379,12 @@ } #endif -static inline struct arpt_table *find_table_lock(const char *name, int *error, struct semaphore *mutex) +static inline struct arpt_table *arpt_find_table_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&arpt_tables, name, "arptable_", error, mutex); } -static inline struct arpt_target *find_target_lock(const char *name, int *error, struct semaphore *mutex) +struct arpt_target *arpt_find_target_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&arpt_target, name, "arpt_", error, mutex); } @@ -535,7 +534,7 @@ } t = arpt_get_target(e); - target = find_target_lock(t->u.user.name, &ret, &arpt_mutex); + target = arpt_find_target_lock(t->u.user.name, &ret, &arpt_mutex); if (!target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); goto out; @@ -834,7 +833,7 @@ int ret; struct arpt_table *t; - t = find_table_lock(entries->name, &ret, &arpt_mutex); + t = arpt_find_table_lock(entries->name, &ret, &arpt_mutex); if (t) { duprintf("t->private->number = %u\n", t->private->number); @@ -900,7 +899,7 @@ duprintf("arp_tables: Translated table\n"); - t = find_table_lock(tmp.name, &ret, &arpt_mutex); + t = arpt_find_table_lock(tmp.name, &ret, &arpt_mutex); if (!t) goto free_newinfo_counters_untrans; @@ -985,7 +984,7 @@ goto free; } - t = find_table_lock(tmp.name, &ret, &arpt_mutex); + t = arpt_find_table_lock(tmp.name, &ret, &arpt_mutex); if (!t) goto free; @@ -1058,7 +1057,7 @@ break; } name[ARPT_TABLE_MAXNAMELEN-1] = '\0'; - t = find_table_lock(name, &ret, &arpt_mutex); + t = arpt_find_table_lock(name, &ret, &arpt_mutex); if (t) { struct arpt_getinfo info; @@ -1306,6 +1305,7 @@ EXPORT_SYMBOL(arpt_register_table); EXPORT_SYMBOL(arpt_unregister_table); EXPORT_SYMBOL(arpt_do_table); +EXPORT_SYMBOL(arpt_find_target_lock); EXPORT_SYMBOL(arpt_register_target); EXPORT_SYMBOL(arpt_unregister_target); --- /usr/src/2426/include/linux/netfilter_ipv6/ip6_tables.h 2003-06-13 10:51:38.000000000 -0400 +++ /usr/src/2426-mod/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-03 22:54:59.000000000 -0400 @@ -106,6 +106,8 @@ u_int64_t pcnt, bcnt; /* Packet and byte counters */ }; +static DECLARE_MUTEX(ip6t_mutex); + /* Values for "flag" field in struct ip6t_ip6 (general ip6 structure). */ #define IP6T_F_PROTO 0x01 /* Set if rule cares about upper protocols */ --- /usr/src/2426/net/ipv6/netfilter/ip6_tables.c 2004-04-14 09:05:41.000000000 -0400 +++ /usr/src/2426-mod/net/ipv6/netfilter/ip6_tables.c 2004-06-03 21:56:59.000000000 -0400 @@ -57,8 +57,6 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) -/* Mutex protects lists (only traversed in user context). */ -static DECLARE_MUTEX(ip6t_mutex); /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ip6t_mutex) != 0) @@ -535,7 +533,7 @@ #endif static inline struct ip6t_table * -find_table_lock(const char *name, int *error, struct semaphore *mutex) +ip6t_find_table_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ip6t_tables, name, "ip6table_", error, mutex); } @@ -546,8 +544,8 @@ return find_inlist_lock(&ip6t_match, name, "ip6t_", error, mutex); } -static inline struct ip6t_target * -find_target_lock(const char *name, int *error, struct semaphore *mutex) +struct ip6t_target * +ip6t_find_target_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ip6t_target, name, "ip6t_", error, mutex); } @@ -764,7 +762,7 @@ goto cleanup_matches; t = ip6t_get_target(e); - target = find_target_lock(t->u.user.name, &ret, &ip6t_mutex); + target = ip6t_find_target_lock(t->u.user.name, &ret, &ip6t_mutex); if (!target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); goto cleanup_matches; @@ -1101,7 +1099,7 @@ int ret; struct ip6t_table *t; - t = find_table_lock(entries->name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(entries->name, &ret, &ip6t_mutex); if (t) { duprintf("t->private->number = %u\n", t->private->number); @@ -1164,7 +1162,7 @@ duprintf("ip_tables: Translated table\n"); - t = find_table_lock(tmp.name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(tmp.name, &ret, &ip6t_mutex); if (!t) goto free_newinfo_counters_untrans; @@ -1258,7 +1256,7 @@ goto free; } - t = find_table_lock(tmp.name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(tmp.name, &ret, &ip6t_mutex); if (!t) goto free; @@ -1333,7 +1331,7 @@ break; } name[IP6T_TABLE_MAXNAMELEN-1] = '\0'; - t = find_table_lock(name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(name, &ret, &ip6t_mutex); if (t) { struct ip6t_getinfo info; @@ -1940,6 +1938,7 @@ EXPORT_SYMBOL(ip6t_register_table); EXPORT_SYMBOL(ip6t_unregister_table); EXPORT_SYMBOL(ip6t_do_table); +EXPORT_SYMBOL(ip6t_find_target_lock); EXPORT_SYMBOL(ip6t_register_match); EXPORT_SYMBOL(ip6t_unregister_match); EXPORT_SYMBOL(ip6t_register_target); --=-q0+k3WAQkq6HY9b92iVN Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=nf26p Content-Type: text/plain; name=nf26p; charset=ISO-8859-1 --- /usr/src/266/include/linux/netfilter.h 2004-05-09 22:32:37.000000000 -0400 +++ /usr/src/266-mod/include/linux/netfilter.h 2004-06-04 10:21:20.000000000 -0400 @@ -171,6 +171,12 @@ struct nf_info *info, unsigned int verdict); +extern inline struct ipt_target * +ipt_find_target_lock(const char *name, int *error, struct semaphore *mutex); +extern inline struct ip6t_target * +ip6t_find_target_lock(const char *name, int *error, struct semaphore *mutex); +extern inline struct arpt_target * +arpt_find_target_lock(const char *name, int *error, struct semaphore *mutex); extern void (*ip_ct_attach)(struct sk_buff *, struct nf_ct_info *); #ifdef CONFIG_NETFILTER_DEBUG --- /usr/src/266/include/linux/netfilter_ipv4/ip_tables.h 2004-05-09 22:32:37.000000000 -0400 +++ /usr/src/266-mod/include/linux/netfilter_ipv4/ip_tables.h 2004-06-04 10:21:20.000000000 -0400 @@ -283,6 +283,8 @@ struct ipt_entry entrytable[0]; }; +extern struct semaphore ipt_mutex; + /* Standard return verdict, or do jump. */ #define IPT_STANDARD_TARGET "" /* Error verdict. */ @@ -334,6 +336,7 @@ /* * Main firewall chains definitions and global var's definitions. */ +static DECLARE_MUTEX(ipt_mutex); #ifdef __KERNEL__ #include @@ -406,6 +409,11 @@ struct module *me; }; +extern struct ipt_target * +ipt_find_target_lock(const char *name, int *error, struct semaphore *mutex); +extern struct arpt_target * +arpt_find_target_lock(const char *name, int *error, struct semaphore *mutex); + extern int ipt_register_target(struct ipt_target *target); extern void ipt_unregister_target(struct ipt_target *target); --- /usr/src/266/net/ipv4/netfilter/ip_tables.c 2004-05-09 22:32:26.000000000 -0400 +++ /usr/src/266-mod/net/ipv4/netfilter/ip_tables.c 2004-06-04 10:21:20.000000000 -0400 @@ -61,9 +61,6 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) -/* Mutex protects lists (only traversed in user context). */ -static DECLARE_MUTEX(ipt_mutex); - /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) #define ASSERT_WRITE_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) @@ -418,7 +415,7 @@ { void *ret; -#if 0 +#if 0 duprintf("find_inlist: searching for `%s' in %s.\n", name, head == &ipt_target ? "ipt_target" : head == &ipt_match ? "ipt_match" @@ -461,7 +458,7 @@ #endif static inline struct ipt_table * -find_table_lock(const char *name, int *error, struct semaphore *mutex) +ipt_find_table_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ipt_tables, name, "iptable_", error, mutex); } @@ -472,8 +469,8 @@ return find_inlist_lock(&ipt_match, name, "ipt_", error, mutex); } -static inline struct ipt_target * -find_target_lock(const char *name, int *error, struct semaphore *mutex) +struct ipt_target * +ipt_find_target_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ipt_target, name, "ipt_", error, mutex); } @@ -688,7 +685,7 @@ goto cleanup_matches; t = ipt_get_target(e); - target = find_target_lock(t->u.user.name, &ret, &ipt_mutex); + target = ipt_find_target_lock(t->u.user.name, &ret, &ipt_mutex); if (!target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); goto cleanup_matches; @@ -1025,7 +1022,7 @@ int ret; struct ipt_table *t; - t = find_table_lock(entries->name, &ret, &ipt_mutex); + t = ipt_find_table_lock(entries->name, &ret, &ipt_mutex); if (t) { duprintf("t->private->number = %u\n", t->private->number); @@ -1092,7 +1089,7 @@ duprintf("ip_tables: Translated table\n"); - t = find_table_lock(tmp.name, &ret, &ipt_mutex); + t = ipt_find_table_lock(tmp.name, &ret, &ipt_mutex); if (!t) goto free_newinfo_counters_untrans; @@ -1195,7 +1192,7 @@ goto free; } - t = find_table_lock(tmp.name, &ret, &ipt_mutex); + t = ipt_find_table_lock(tmp.name, &ret, &ipt_mutex); if (!t) goto free; @@ -1270,7 +1267,7 @@ break; } name[IPT_TABLE_MAXNAMELEN-1] = '\0'; - t = find_table_lock(name, &ret, &ipt_mutex); + t = ipt_find_table_lock(name, &ret, &ipt_mutex); if (t) { struct ipt_getinfo info; @@ -1855,6 +1852,7 @@ EXPORT_SYMBOL(ipt_do_table); EXPORT_SYMBOL(ipt_register_target); EXPORT_SYMBOL(ipt_unregister_target); +EXPORT_SYMBOL(ipt_find_target_lock); module_init(init); module_exit(fini); --- /usr/src/266/include/linux/netfilter_arp.h 2004-05-09 22:32:00.000000000 -0400 +++ /usr/src/266-mod/include/linux/netfilter_arp.h 2004-06-04 10:21:20.000000000 -0400 @@ -17,4 +17,5 @@ #define NF_ARP_FORWARD 2 #define NF_ARP_NUMHOOKS 3 +static DECLARE_MUTEX(arpt_mutex); #endif /* __LINUX_ARP_NETFILTER_H */ --- /usr/src/266/net/ipv4/netfilter/arp_tables.c 2004-05-09 22:33:12.000000000 -0400 +++ /usr/src/266-mod/net/ipv4/netfilter/arp_tables.c 2004-06-04 10:21:20.000000000 -0400 @@ -56,7 +56,6 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) -static DECLARE_MUTEX(arpt_mutex); #define ASSERT_READ_LOCK(x) ARP_NF_ASSERT(down_trylock(&arpt_mutex) != 0) #define ASSERT_WRITE_LOCK(x) ARP_NF_ASSERT(down_trylock(&arpt_mutex) != 0) @@ -388,12 +387,12 @@ } #endif -static inline struct arpt_table *find_table_lock(const char *name, int *error, struct semaphore *mutex) +static inline struct arpt_table *arpt_find_table_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&arpt_tables, name, "arptable_", error, mutex); } -static inline struct arpt_target *find_target_lock(const char *name, int *error, struct semaphore *mutex) +struct arpt_target *arpt_find_target_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&arpt_target, name, "arpt_", error, mutex); } @@ -543,7 +542,7 @@ } t = arpt_get_target(e); - target = find_target_lock(t->u.user.name, &ret, &arpt_mutex); + target = arpt_find_target_lock(t->u.user.name, &ret, &arpt_mutex); if (!target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); goto out; @@ -843,7 +842,7 @@ int ret; struct arpt_table *t; - t = find_table_lock(entries->name, &ret, &arpt_mutex); + t = arpt_find_table_lock(entries->name, &ret, &arpt_mutex); if (t) { duprintf("t->private->number = %u\n", t->private->number); @@ -909,7 +908,7 @@ duprintf("arp_tables: Translated table\n"); - t = find_table_lock(tmp.name, &ret, &arpt_mutex); + t = arpt_find_table_lock(tmp.name, &ret, &arpt_mutex); if (!t) goto free_newinfo_counters_untrans; @@ -1002,7 +1001,7 @@ goto free; } - t = find_table_lock(tmp.name, &ret, &arpt_mutex); + t = arpt_find_table_lock(tmp.name, &ret, &arpt_mutex); if (!t) goto free; @@ -1075,7 +1074,7 @@ break; } name[ARPT_TABLE_MAXNAMELEN-1] = '\0'; - t = find_table_lock(name, &ret, &arpt_mutex); + t = arpt_find_table_lock(name, &ret, &arpt_mutex); if (t) { struct arpt_getinfo info; @@ -1323,6 +1322,7 @@ EXPORT_SYMBOL(arpt_register_table); EXPORT_SYMBOL(arpt_unregister_table); EXPORT_SYMBOL(arpt_do_table); +EXPORT_SYMBOL(arpt_find_target_lock); EXPORT_SYMBOL(arpt_register_target); EXPORT_SYMBOL(arpt_unregister_target); --- /usr/src/266/include/linux/netfilter_ipv6/ip6_tables.h 2004-05-09 22:33:20.000000000 -0400 +++ /usr/src/266-mod/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-04 10:21:20.000000000 -0400 @@ -106,6 +106,8 @@ u_int64_t pcnt, bcnt; /* Packet and byte counters */ }; +static DECLARE_MUTEX(ip6t_mutex); + /* Values for "flag" field in struct ip6t_ip6 (general ip6 structure). */ #define IP6T_F_PROTO 0x01 /* Set if rule cares about upper protocols */ --- /usr/src/266/net/ipv6/netfilter/ip6_tables.c 2004-05-09 22:33:19.000000000 -0400 +++ /usr/src/266-mod/net/ipv6/netfilter/ip6_tables.c 2004-06-04 10:21:20.000000000 -0400 @@ -66,8 +66,6 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) -/* Mutex protects lists (only traversed in user context). */ -static DECLARE_MUTEX(ip6t_mutex); /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ip6t_mutex) != 0) @@ -544,7 +542,7 @@ #endif static inline struct ip6t_table * -find_table_lock(const char *name, int *error, struct semaphore *mutex) +ip6t_find_table_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ip6t_tables, name, "ip6table_", error, mutex); } @@ -555,8 +553,8 @@ return find_inlist_lock(&ip6t_match, name, "ip6t_", error, mutex); } -static inline struct ip6t_target * -find_target_lock(const char *name, int *error, struct semaphore *mutex) +struct ip6t_target * +ip6t_find_target_lock(const char *name, int *error, struct semaphore *mutex) { return find_inlist_lock(&ip6t_target, name, "ip6t_", error, mutex); } @@ -771,7 +769,7 @@ goto cleanup_matches; t = ip6t_get_target(e); - target = find_target_lock(t->u.user.name, &ret, &ip6t_mutex); + target = ip6t_find_target_lock(t->u.user.name, &ret, &ip6t_mutex); if (!target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); goto cleanup_matches; @@ -1111,7 +1109,7 @@ int ret; struct ip6t_table *t; - t = find_table_lock(entries->name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(entries->name, &ret, &ip6t_mutex); if (t) { duprintf("t->private->number = %u\n", t->private->number); @@ -1174,7 +1172,7 @@ duprintf("ip_tables: Translated table\n"); - t = find_table_lock(tmp.name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(tmp.name, &ret, &ip6t_mutex); if (!t) goto free_newinfo_counters_untrans; @@ -1276,7 +1274,7 @@ goto free; } - t = find_table_lock(tmp.name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(tmp.name, &ret, &ip6t_mutex); if (!t) goto free; @@ -1351,7 +1349,7 @@ break; } name[IP6T_TABLE_MAXNAMELEN-1] = '\0'; - t = find_table_lock(name, &ret, &ip6t_mutex); + t = ip6t_find_table_lock(name, &ret, &ip6t_mutex); if (t) { struct ip6t_getinfo info; @@ -1964,6 +1962,7 @@ EXPORT_SYMBOL(ip6t_register_table); EXPORT_SYMBOL(ip6t_unregister_table); EXPORT_SYMBOL(ip6t_do_table); +EXPORT_SYMBOL(ip6t_find_target_lock); EXPORT_SYMBOL(ip6t_register_match); EXPORT_SYMBOL(ip6t_unregister_match); EXPORT_SYMBOL(ip6t_register_target); --=-q0+k3WAQkq6HY9b92iVN-- From margitsw@t-online.de Sat Jun 5 05:04:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 05:05:02 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55C4sgi028006 for ; Sat, 5 Jun 2004 05:04:55 -0700 Received: from fwd11.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1BWYmY-0005ET-02; Sat, 05 Jun 2004 12:52:10 +0200 Received: from roglap.local (bVj0BEZTre2P6XYzQkzjPnaIzWDlQYu4fZV35gqnfi7mH1uKDnv5ZX@[217.224.28.133]) by fwd11.sul.t-online.com with esmtp id 1BWYmL-1KPzqS0; Sat, 5 Jun 2004 12:51:57 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 10/17 linux-2.6.7-rc2] prism54: Fix bug 77, strengthened oid txn (resend) Date: Sat, 5 Jun 2004 14:49:39 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_jFcwAw/FU/M0bFU" Message-Id: <200406051449.39098.margitsw@t-online.de> X-Seen: false X-ID: bVj0BEZTre2P6XYzQkzjPnaIzWDlQYu4fZV35gqnfi7mH1uKDnv5ZX X-archive-position: 5634 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: 13017 Lines: 395 --Boundary-00=_jFcwAw/FU/M0bFU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-04-09 Aurelien Alleaume * oid_mgt.c, isl_ioctl.c : Cleanups. Bug #77. Minor stuffs. * islpci_mgt.c (islpci_mgt_transaction) : enforce serialization in oid transaction. lindent.sh. * islpci_mgt.c (islpci_mgt_transaction) : Strengthened oid transaction. --Boundary-00=_jFcwAw/FU/M0bFU Content-Type: text/x-diff; charset="us-ascii"; name="10-fix-bug-77-enforce-serialization.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="10-fix-bug-77-enforce-serialization.patch" diff -NaurEb linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.6ct/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 14:44:24.886289992 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-05-28 15:08:00.681056472 +0200 @@ -204,7 +204,7 @@ /* Noise floor. * I'm not sure if the unit is dBm. - * Note : If we are not connected, this value seems to be irrevelant. */ + * Note : If we are not connected, this value seems to be irrelevant. */ mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); priv->local_iwstatistics.qual.noise = r.u; @@ -216,8 +216,7 @@ data = r.ptr; /* copy this MAC to the bss */ - for (j = 0; j < 6; j++) - bss.address[j] = data[j]; + memcpy(bss.address, data, 6); kfree(data); /* now ask for the corresponding bss */ @@ -505,7 +504,7 @@ return 0; /* Request the device for the supported frequencies - * not really revelant since some devices will report the 5 GHz band + * not really relevant since some devices will report the 5 GHz band * frequencies even if they don't support them. */ rvalue = @@ -515,21 +514,12 @@ range->num_channels = freq->nr; range->num_frequency = freq->nr; - /* Frequencies are not listed in the right order. The reordering is probably - * firmware dependant and thus should work for everyone. - */ m = min(IW_MAX_FREQUENCIES, (int) freq->nr); - for (i = 0; i < m - 12; i++) { - range->freq[i].m = freq->mhz[12 + i]; - range->freq[i].e = 6; - range->freq[i].i = i + 1; - } - for (i = m - 12; i < m; i++) { - range->freq[i].m = freq->mhz[i - m + 12]; + for (i = 0; i < m; i++) { + range->freq[i].m = freq->mhz[i]; range->freq[i].e = 6; - range->freq[i].i = i + 23; + range->freq[i].i = channel_of_freq(freq->mhz[i]); } - kfree(freq); rvalue |= mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r); @@ -1967,60 +1957,6 @@ } int -prism54_set_maxframeburst(struct net_device *ndev, struct iw_request_info *info, - __u32 * uwrq, char *extra) -{ - islpci_private *priv = netdev_priv(ndev); - u32 max_burst; - - max_burst = (*uwrq) ? *uwrq : CARD_DEFAULT_MAXFRAMEBURST; - mgt_set_request(priv, DOT11_OID_MAXFRAMEBURST, 0, &max_burst); - - return -EINPROGRESS; /* Call commit handler */ -} - -int -prism54_get_maxframeburst(struct net_device *ndev, struct iw_request_info *info, - __u32 * uwrq, char *extra) -{ - islpci_private *priv = netdev_priv(ndev); - union oid_res_t r; - int rvalue; - - rvalue = mgt_get_request(priv, DOT11_OID_MAXFRAMEBURST, 0, NULL, &r); - *uwrq = r.u; - - return rvalue; -} - -int -prism54_set_profile(struct net_device *ndev, struct iw_request_info *info, - __u32 * uwrq, char *extra) -{ - islpci_private *priv = netdev_priv(ndev); - u32 profile; - - profile = (*uwrq) ? *uwrq : CARD_DEFAULT_PROFILE; - mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); - - return -EINPROGRESS; /* Call commit handler */ -} - -int -prism54_get_profile(struct net_device *ndev, struct iw_request_info *info, - __u32 * uwrq, char *extra) -{ - islpci_private *priv = netdev_priv(ndev); - union oid_res_t r; - int rvalue; - - rvalue = mgt_get_request(priv, DOT11_OID_PROFILES, 0, NULL, &r); - *uwrq = r.u; - - return rvalue; -} - -int prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2099,7 +2035,7 @@ } } - return ret; + return (ret ? ret : -EINPROGRESS); } static int @@ -2205,16 +2141,16 @@ #define PRISM54_GET_PRISMHDR SIOCIWFIRSTPRIV+23 #define PRISM54_SET_PRISMHDR SIOCIWFIRSTPRIV+24 -#define IWPRIV_SET_U32(n,x) { n, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, "set_"x } -#define IWPRIV_SET_SSID(n,x) { n, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | 1, 0, "set_"x } -#define IWPRIV_SET_ADDR(n,x) { n, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, "set_"x } -#define IWPRIV_GET(n,x) { n, 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | PRIV_STR_SIZE, "get_"x } +#define IWPRIV_SET_U32(n,x) { n, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, "s_"x } +#define IWPRIV_SET_SSID(n,x) { n, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | 1, 0, "s_"x } +#define IWPRIV_SET_ADDR(n,x) { n, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, "s_"x } +#define IWPRIV_GET(n,x) { n, 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | PRIV_STR_SIZE, "g_"x } #define IWPRIV_U32(n,x) IWPRIV_SET_U32(n,x), IWPRIV_GET(n,x) #define IWPRIV_SSID(n,x) IWPRIV_SET_SSID(n,x), IWPRIV_GET(n,x) #define IWPRIV_ADDR(n,x) IWPRIV_SET_ADDR(n,x), IWPRIV_GET(n,x) -/* Note : limited to 128 private ioctls */ +/* Note : limited to 128 private ioctls (wireless tools 26) */ static const struct iw_priv_args prism54_private_args[] = { /*{ cmd, set_args, get_args, name } */ @@ -2352,5 +2288,6 @@ int prism54_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) { + return -EOPNOTSUPP; } diff -NaurEb linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_mgt.c 2004-05-28 14:40:26.998454440 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_mgt.c 2004-05-28 15:08:00.686055712 +0200 @@ -63,7 +63,6 @@ Queue handling for management frames ******************************************************************************/ - /* * Helper function to create a PIMFOR management frame header. */ @@ -87,7 +86,7 @@ pimfor_header_t *h = data; while ((void *) h < data + len) { - if(h->flags & PIMFOR_FLAG_LITTLE_ENDIAN) { + if (h->flags & PIMFOR_FLAG_LITTLE_ENDIAN) { le32_to_cpus(&h->oid); le32_to_cpus(&h->length); } else { @@ -124,7 +123,8 @@ if (buf->mem == NULL) { buf->mem = kmalloc(MGMT_FRAME_SIZE, GFP_ATOMIC); if (!buf->mem) { - printk(KERN_WARNING "Error allocating management frame.\n"); + printk(KERN_WARNING + "Error allocating management frame.\n"); return -ENOMEM; } buf->size = MGMT_FRAME_SIZE; @@ -133,8 +133,9 @@ buf->pci_addr = pci_map_single(priv->pdev, buf->mem, MGMT_FRAME_SIZE, PCI_DMA_FROMDEVICE); - if(!buf->pci_addr) { - printk(KERN_WARNING "Failed to make memory DMA'able\n."); + if (!buf->pci_addr) { + printk(KERN_WARNING + "Failed to make memory DMA'able\n."); return -ENOMEM; } } @@ -149,8 +150,7 @@ * been written before announcing the frame buffer to * device */ wmb(); - cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] = - cpu_to_le32(curr); + cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] = cpu_to_le32(curr); } return 0; } @@ -249,7 +249,7 @@ * been written before announcing the frame buffer to * device */ wmb(); - cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ] = cpu_to_le32(curr_frag+1); + cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ] = cpu_to_le32(curr_frag + 1); spin_unlock_irqrestore(&priv->slock, flags); /* trigger the device */ @@ -281,14 +281,13 @@ DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive \n"); #endif - /* Only once per interrupt, determine fragment range to * process. This avoids an endless loop (i.e. lockup) if * frames come in faster than we can process them. */ curr_frag = le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_RX_MGMTQ]); barrier(); - for ( ; priv->index_mgmt_rx < curr_frag; priv->index_mgmt_rx++) { + for (; priv->index_mgmt_rx < curr_frag; priv->index_mgmt_rx++) { pimfor_header_t *header; u32 index = priv->index_mgmt_rx % ISL38XX_CB_MGMT_QSIZE; struct islpci_membuf *buf = &priv->mgmt_rx[index]; @@ -298,7 +297,7 @@ /* I have no idea (and no documentation) if flags != 0 * is possible. Drop the frame, reuse the buffer. */ - if(le16_to_cpu(cb->rx_data_mgmt[index].flags) != 0) { + if (le16_to_cpu(cb->rx_data_mgmt[index].flags) != 0) { printk(KERN_WARNING "%s: unknown flags 0x%04x\n", ndev->name, le16_to_cpu(cb->rx_data_mgmt[index].flags)); @@ -314,8 +313,7 @@ * triggers, we likely have kernel heap corruption. */ if (frag_len > MGMT_FRAME_SIZE) { printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\ -n", - ndev->name, frag_len, frag_len); +n", ndev->name, frag_len, frag_len); frag_len = MGMT_FRAME_SIZE; } @@ -344,23 +342,25 @@ /* display the buffer contents for debugging */ display_buffer((char *) header, PIMFOR_HEADER_SIZE); - display_buffer((char *) header + PIMFOR_HEADER_SIZE, header->length); + display_buffer((char *) header + PIMFOR_HEADER_SIZE, + header->length); #endif /* nobody sends these */ if (header->flags & PIMFOR_FLAG_APPLIC_ORIGIN) { - printk(KERN_DEBUG "%s: errant PIMFOR application frame\n", + printk(KERN_DEBUG + "%s: errant PIMFOR application frame\n", ndev->name); continue; } /* Determine frame size, skipping OID_INL_TUNNEL headers. */ size = PIMFOR_HEADER_SIZE + header->length; - frame = kmalloc(sizeof(struct islpci_mgmtframe) + size, + frame = kmalloc(sizeof (struct islpci_mgmtframe) + size, GFP_ATOMIC); if (!frame) { - printk(KERN_WARNING "%s: Out of memory, cannot handle oid 0x%08x\n", - + printk(KERN_WARNING + "%s: Out of memory, cannot handle oid 0x%08x\n", ndev->name, header->oid); continue; } @@ -392,14 +392,13 @@ /* Signal the one waiting process that a response * has been received. */ if ((frame = xchg(&priv->mgmt_received, frame)) != NULL) { - printk(KERN_WARNING "%s: mgmt response not collected\n", + printk(KERN_WARNING + "%s: mgmt response not collected\n", ndev->name); kfree(frame); } - #if VERBOSE > SHOW_ERROR_MESSAGES - DEBUG(SHOW_TRACING, - "Wake up Mgmt Queue\n"); + DEBUG(SHOW_TRACING, "Wake up Mgmt Queue\n"); #endif wake_up(&priv->mgmt_wqueue); } @@ -431,7 +430,7 @@ curr_frag = le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_TX_MGMTQ]); barrier(); - for ( ; priv->index_mgmt_tx < curr_frag; priv->index_mgmt_tx++) { + for (; priv->index_mgmt_tx < curr_frag; priv->index_mgmt_tx++) { int index = priv->index_mgmt_tx % ISL38XX_CB_MGMT_QSIZE; struct islpci_membuf *buf = &priv->mgmt_tx[index]; pci_unmap_single(priv->pdev, buf->pci_addr, buf->size, @@ -463,7 +462,7 @@ prepare_to_wait(&priv->mgmt_wqueue, &wait, TASK_UNINTERRUPTIBLE); err = islpci_mgt_transmit(ndev, operation, oid, senddata, sendlen); - if(err) + if (err) goto out; err = -ETIMEDOUT; @@ -474,12 +473,22 @@ timeleft = schedule_timeout(wait_cycle_jiffies); frame = xchg(&priv->mgmt_received, NULL); if (frame) { + if (frame->header->oid == oid) { *recvframe = frame; err = 0; goto out; + } else { + printk(KERN_DEBUG + "%s: expecting oid 0x%x, received 0x%x.\n", + ndev->name, (unsigned int) oid, + frame->header->oid); + kfree(frame); + frame = NULL; } - if(timeleft == 0) { - printk(KERN_DEBUG "%s: timeout waiting for mgmt response %lu, trigging device\n", + } + if (timeleft == 0) { + printk(KERN_DEBUG + "%s: timeout waiting for mgmt response %lu, trigging device\n", ndev->name, timeout_left); islpci_trigger(priv); } diff -NaurEb linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.6ct/drivers/net/wireless/prism54/oid_mgt.c 2004-05-28 14:44:24.888289688 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/oid_mgt.c 2004-05-28 15:08:00.688055408 +0200 @@ -40,17 +40,13 @@ if ((f >= 2412) && (f <= 2484)) { while ((c < 14) && (f != frequency_list_bg[c])) c++; - if (c >= 14) - return 0; + return (c >= 14) ? 0 : ++c; } else if ((f >= (int) 5170) && (f <= (int) 5320)) { while ((c < 12) && (f != frequency_list_a[c])) c++; - if (c >= 12) - return 0; + return (c >= 12) ? 0 : (c + 37); } else return 0; - - return ++c; } #define OID_STRUCT(name,oid,s,t) [name] = {oid, 0, sizeof(s), t} --Boundary-00=_jFcwAw/FU/M0bFU-- From mikpe@user.it.uu.se Sat Jun 5 05:15:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 05:15:17 -0700 (PDT) Received: from aun.it.uu.se (root@aun.it.uu.se [130.238.12.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55CF9gi028531 for ; Sat, 5 Jun 2004 05:15:10 -0700 Received: from harpo.it.uu.se (daemon@harpo.it.uu.se [130.238.12.34]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i55CF4RE019159; Sat, 5 Jun 2004 14:15:04 +0200 (MEST) Received: (from mikpe@localhost) by harpo.it.uu.se (8.12.10+Sun/8.12.10) id i55CF4hH004189; Sat, 5 Jun 2004 14:15:04 +0200 (MEST) Date: Sat, 5 Jun 2004 14:15:04 +0200 (MEST) Message-Id: <200406051215.i55CF4hH004189@harpo.it.uu.se> From: Mikael Pettersson To: jgarzik@pobox.com Subject: Re: PROBLEM: network driver causes kernel panic Cc: dctucker@hotmail.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com X-archive-position: 5635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mikpe@csd.uu.se Precedence: bulk X-list: netdev Content-Length: 1381 Lines: 44 On Fri, 04 Jun 2004 16:47:13 -0400, Jeff Garzik wrote: >Mikael Pettersson wrote: >> This confirms that eth1 is a 21041 driven by the de2104x driver. >> >> I've seen something very similar to Casey's problem, on a PowerMac >> with a built-in 21041. Booting it with no network cable connected >> causes a timer to hit a BUG() in de2104x about a second after >> the device is ifup:d. >> >> The 2.4 kernel's tulip driver works just fine. >> >> I reported this last year, but nothing happened. > > >Well, I'm very interested in debugging it. There were a flurry of >de2104x patches in the past year, I thought that took care of the issues. > >Please email details to netdev@oss.sgi.com and jgarzik@pobox.com... Booting 2.6.7-rc1 with the de2104x driver built-in and eth0 disconnected from the LAN leads to the following oops about a second after INIT tried to ifup eth0: eth0: timeout expired stopping DMA kernel BUG in de_set_media at drivers/net/tulip/de2104x.c:919! Call trace: de21041_media_timer run_timer_softirq __do_softirq do_softirq timer_interrupt ret_from_except ppc6xx_idle cpu_idle rest_init start_kernel The PowerPC kernel decides to panic() after a brief delay at this point, so I can't capture the oops text except by typing it down manually. Besides, I doubt the ppc register dump would be useful; we know which BUG() was hit. /Mikael From hadi@cyberus.ca Sat Jun 5 07:38:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 07:38:39 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55EcZgi031387 for ; Sat, 5 Jun 2004 07:38:35 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BWcJc-0008A2-Fi for netdev@oss.sgi.com; Sat, 05 Jun 2004 10:38:32 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BWcJZ-0006Jq-3X; Sat, 05 Jun 2004 10:38:29 -0400 Subject: RE: TxDescriptors -> 1024 default. Please not for every NIC! From: jamal Reply-To: hadi@cyberus.ca To: Cheng Jin Cc: Marc Herbert , "netdev@oss.sgi.com" In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1086446277.1592.205.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jun 2004 10:37:57 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5636 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: 2387 Lines: 55 On Wed, 2004-06-02 at 15:49, Cheng Jin wrote: > Marc, > > In general, I very much agree with what you have stated about not having > a large txqueuelen. Txqueuelen should be something that alleviates > the mismatch between CPU speed and NIC transmission speed, Thats the theory. More interesting of course are bus speeds, arbitration schemes, RAM latencies and throughput and other dynamic bottlenecks like system loads. > temporarily. > As long as the txqueuelne is greater than zero, say 10 just to be safe, > NIC will be running at full speed (unless there were inefficiencies in > scheduling) so there is no incentive in setting it to be an excessively > large value like 1000. In theory as well, the only time you even need to queue is when theres congestion.. In reality, totaly different ballgame. In other words its not a simple system that you can throw Littles theorems at. Marc, good email, at least you didnt hand wave and declare the wind was blowing towards the south today. My opinion: I agree that the 1000 qlen is excessive for 10/100 - infact i think the value should dynamically adjust itself even for gige capable NICs (example if a gige NIC negotiates a 10Mbps speed with link partner, then you should adjust the qlen)[1]. That wont be trivial to do - but more importantly motivation lacks because i dont think the situation we have right now is devastating. To clarify: A single TCP flow will fill in any pipe you give it under proper conditions (proper congestion control algorithms, buffer etc)[2]. Most apps using TCP dont care very much about latency; the only exception would be some scientific clustering technologies using TCP for control messaging. And for those type of apps, you should be able to tune the qlen to your liking using tc or ip utilities (I claim they shouldnt be using tcp to begin with, but thats another discussion). If you dont want to take that extra step to tune then you dont care, and IMO you shouldnt complain. Having said all that: i still think theres value in maybe issuing a warning or making the default qlen selection a compile time config. cheers, jamal [1] I think it would make a nice project for someone with time. I can consult for anyone interested. [2] Looking at the recent patches on BIC, it does seem pretty agressive and should have no problem filling a 10Gige pipe with proper processing power. From pp@ee.oulu.fi Sat Jun 5 13:06:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 13:06:54 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55K6jgi013461 for ; Sat, 5 Jun 2004 13:06:46 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id i55K6iwx010179; Sat, 5 Jun 2004 23:06:44 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i55K6i2l002757; Sat, 5 Jun 2004 23:06:44 +0300 (EEST) Date: Sat, 5 Jun 2004 23:06:44 +0300 From: Pekka Pietikainen To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040605200643.GA2210@ee.oulu.fi> References: <20040531202104.GA8301@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20040531202104.GA8301@ee.oulu.fi> User-Agent: Mutt/1.4.2i X-archive-position: 5637 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: 4072 Lines: 139 On Mon, May 31, 2004 at 11:21:04PM +0300, Pekka Pietikainen wrote: > After diagnosing > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165 > for a while > > it seems that bcm4401 is quite broken when DMA:ing from/to > addresses that are > 1GB. This only is a problem with > 1GB of physical > memory and when using a 4:4 split. And here's a workaround-everything-in-the-driver version that makes everything work. Cc:d to linux-kernel to get wider coverage. There _really_ has to be a better way of dealing with hardware problems like this (with a 512 entry TX ring this uses almost 800k of GFP_DMA, probably should be made smaller in any case...): (And again, please prepare your barf-bags!) --- ../b44.c 2004-06-05 22:54:50.210817784 +0300 +++ b44.c 2004-06-05 22:54:56.721827960 +0300 @@ -67,6 +67,7 @@ #define NEXT_TX(N) (((N) + 1) & (B44_TX_RING_SIZE - 1)) #define RX_PKT_BUF_SZ (1536 + bp->rx_offset + 64) +#define TX_PKT_BUF_SZ (B44_MAX_MTU + ETH_HLEN + 8) /* minimum number of free TX descriptors required to wake up TX process */ #define B44_TX_WAKEUP_THRESH (B44_TX_RING_SIZE / 4) @@ -82,6 +83,12 @@ static int b44_debug = -1; /* -1 == use B44_DEF_MSG_ENABLE as value */ +/* Hardware bug work-around, the chip seems to be unable to do PCI DMA + to anything above 1GB :-( */ + +#define B44_DMA_MASK 0x3fffffff +static int b44_use_bounce_buffers = 0; + static struct pci_device_id b44_pci_tbl[] = { { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, @@ -634,7 +641,13 @@ src_map = &bp->rx_buffers[src_idx]; dest_idx = dest_idx_unmasked & (B44_RX_RING_SIZE - 1); map = &bp->rx_buffers[dest_idx]; - skb = dev_alloc_skb(RX_PKT_BUF_SZ); + + if(!b44_use_bounce_buffers) { + skb = dev_alloc_skb(RX_PKT_BUF_SZ); + } else { + /* Sigh... */ + skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_DMA); + } if (skb == NULL) return -ENOMEM; @@ -918,6 +931,10 @@ } entry = bp->tx_prod; + if(virt_to_bus(skb->data) + skb->len > B44_PCI_DMA_MAX) { + memcpy(bp->tx_bufs+entry*TX_PKT_BUF_SZ,skb->data,skb->len); + skb->data=bp->tx_bufs+entry*TX_PKT_BUF_SZ; + } mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE); bp->tx_buffers[entry].skb = skb; @@ -1066,6 +1083,11 @@ bp->tx_ring, bp->tx_ring_dma); bp->tx_ring = NULL; } + if (bp->tx_bufs) { + pci_free_consistent(bp->pdev, B44_TX_RING_SIZE * TX_PKT_BUF_SZ, + bp->tx_bufs, bp->tx_bufs_dma); + bp->tx_bufs = NULL; + } } /* @@ -1088,6 +1110,13 @@ goto out_err; memset(bp->tx_buffers, 0, size); + if(b44_use_bounce_buffers) { + size = B44_TX_RING_SIZE * TX_PKT_BUF_SZ; + bp->tx_bufs = pci_alloc_consistent(bp->pdev, size, &bp->tx_bufs_dma); + if (!bp->tx_bufs) + goto out_err; + memset(bp->tx_bufs, 0, size); + } size = DMA_TABLE_BYTES; bp->rx_ring = pci_alloc_consistent(bp->pdev, size, &bp->rx_ring_dma); if (!bp->rx_ring) @@ -1724,12 +1753,25 @@ pci_set_master(pdev); - err = pci_set_dma_mask(pdev, (u64) 0xffffffff); +#ifdef CONFIG_X86_4G + /* XXX only set if > 1GB of physmem */ + b44_use_bounce_buffers=1; +#endif + err = pci_set_dma_mask(pdev, (u64) B44_DMA_MASK); if (err) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); goto err_out_free_res; } + + if(b44_use_bounce_buffers) { + err = pci_set_consistent_dma_mask(pdev, (u64) B44_DMA_MASK); + if (err) { + printk(KERN_ERR PFX "No usable DMA configuration, " + "aborting.\n"); + goto err_out_free_res; + } + } b44reg_base = pci_resource_start(pdev, 0); b44reg_len = pci_resource_len(pdev, 0); --- ../b44.h 2004-06-04 20:03:16.000000000 +0300 +++ b44.h 2004-06-05 21:45:19.000000000 +0300 @@ -503,6 +503,7 @@ struct ring_info *rx_buffers; struct ring_info *tx_buffers; + unsigned char *tx_bufs; u32 dma_offset; u32 flags; @@ -534,7 +535,7 @@ struct pci_dev *pdev; struct net_device *dev; - dma_addr_t rx_ring_dma, tx_ring_dma; + dma_addr_t rx_ring_dma, tx_ring_dma,tx_bufs_dma; u32 rx_pending; u32 tx_pending; From davem@redhat.com Sat Jun 5 13:21:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 13:21:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55KLkgi013964 for ; Sat, 5 Jun 2004 13:21:46 -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 i55KLhi5023602; Sat, 5 Jun 2004 16:21:43 -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 i55KLh018579; Sat, 5 Jun 2004 16:21:43 -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 i55KLXsi018996; Sat, 5 Jun 2004 16:21:33 -0400 Date: Sat, 5 Jun 2004 13:19:23 -0700 From: "David S. Miller" To: Pekka Pietikainen Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-Id: <20040605131923.232f8950.davem@redhat.com> In-Reply-To: <20040605200643.GA2210@ee.oulu.fi> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5638 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: 248 Lines: 9 On Sat, 5 Jun 2004 23:06:44 +0300 Pekka Pietikainen wrote: > + if(virt_to_bus(skb->data) + skb->len > B44_PCI_DMA_MAX) { You can't use this non-portable interface, you have to: 1) pci_map the data 2) test the dma_addr_t returned From davem@redhat.com Sat Jun 5 14:04:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:04:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55L4Ggi015386 for ; Sat, 5 Jun 2004 14:04:16 -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 i55L4Fi5030368; Sat, 5 Jun 2004 17:04:15 -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 i55L4F027350; Sat, 5 Jun 2004 17:04:15 -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 i55L44Ip028932; Sat, 5 Jun 2004 17:04:04 -0400 Date: Sat, 5 Jun 2004 14:01:53 -0700 From: "David S. Miller" To: Olaf Hering Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605140153.6c5945a0.davem@redhat.com> In-Reply-To: <20040605204334.GA1134@suse.de> References: <20040605204334.GA1134@suse.de> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5639 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: 729 Lines: 17 On Sat, 5 Jun 2004 22:43:34 +0200 Olaf Hering wrote: > packet_recvmsg() gets the flags from the compat_sys_socketcall(), but it > does not check for the active MSG_CMSG_COMPAT bit. As a result, it > returns -EINVAL and makes the user rather unhappy Not just packet_recvmsg() (frankly, I'm stumped how tcpdump is working on my sparc64 boxes due to this bug!), every other sendmsg/recvmsg implementation has a test like this verifying the msg_flags for bogons. Let's ask a better question, why do we need to pass this thing down into the implementations anyways? I can't see a reason, can anyone else? If there is no reason, the right fix is simply to mask it out at the top level, for both sendmsg and recvmsg. From davem@redhat.com Sat Jun 5 14:08:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:08:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55L86gi015783 for ; Sat, 5 Jun 2004 14:08:06 -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 i55L85i5031047; Sat, 5 Jun 2004 17:08:05 -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 i55L85028236; Sat, 5 Jun 2004 17:08:05 -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 i55L7smm030208; Sat, 5 Jun 2004 17:07:55 -0400 Date: Sat, 5 Jun 2004 14:05:44 -0700 From: "David S. Miller" To: "David S. Miller" Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605140544.0de4034d.davem@redhat.com> In-Reply-To: <20040605140153.6c5945a0.davem@redhat.com> References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5640 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: 487 Lines: 16 [ Replying to myself :-) ] On Sat, 5 Jun 2004 14:01:53 -0700 "David S. Miller" wrote: > Let's ask a better question, why do we need to pass this thing down > into the implementations anyways? It's for net/core/scm.c handling, sigh. This means also that Olaf's patch is broken, when CONFIG_COMPAT is not set, MSG_CMSG_COMPAT is zero, thus ~MSG_CMSG_COMPAT is the unexpected value all 1's thus breaking the tests for unexpected flags completely. Any better ideas? From olh@suse.de Sat Jun 5 14:24:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:24:39 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55LOMgi016463 for ; Sat, 5 Jun 2004 14:24: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 7566269EF61; Sat, 5 Jun 2004 22:43:35 +0200 (CEST) Date: Sat, 5 Jun 2004 22:43:34 +0200 From: Olaf Hering To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-ID: <20040605204334.GA1134@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i55LOMgi016463 X-archive-position: 5641 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: 774 Lines: 23 packet_recvmsg() gets the flags from the compat_sys_socketcall(), but it does not check for the active MSG_CMSG_COMPAT bit. As a result, it returns -EINVAL and makes the user rather unhappy diff -purN linux-2.6.7-rc2-bk5.orig/net/packet/af_packet.c linux-2.6.7-rc2-bk5/net/packet/af_packet.c --- linux-2.6.7-rc2-bk5.orig/net/packet/af_packet.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/packet/af_packet.c 2004-06-05 22:32:16.000000000 +0200 @@ -1037,7 +1037,7 @@ static int packet_recvmsg(struct kiocb * int copied, err; err = -EINVAL; - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) goto out; #if 0 -- USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG From davem@redhat.com Sat Jun 5 14:39:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:39:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Ldbgi017128 for ; Sat, 5 Jun 2004 14:39:37 -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 i55Ldai5003042; Sat, 5 Jun 2004 17:39: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 i55Lda000853; Sat, 5 Jun 2004 17:39: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 i55LdPIW003432; Sat, 5 Jun 2004 17:39:26 -0400 Date: Sat, 5 Jun 2004 14:37:14 -0700 From: "David S. Miller" To: Olaf Hering Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605143714.729744f8.davem@redhat.com> In-Reply-To: <20040605211701.GD1134@suse.de> References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605211701.GD1134@suse.de> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5643 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: 596 Lines: 16 On Sat, 5 Jun 2004 23:17:01 +0200 Olaf Hering wrote: > On Sat, Jun 05, David S. Miller wrote: > > > I can't see a reason, can anyone else? If there is no reason, the > > right fix is simply to mask it out at the top level, for both > > sendmsg and recvmsg. > > I did it first this way, but the result was a long delay until the dhcp > server replied, the patch sent earlier leads to a fast reply. > > err = sock_recvmsg(sock, &msg_sys, total_len, flags & ~MSG_CMSG_COMPAT); See my other email, net/core/scm.c needs this bit set all the way down into the implementations. From davem@redhat.com Sat Jun 5 14:39:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:39:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55LdCgi017025 for ; Sat, 5 Jun 2004 14:39: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 i55LdBi5002988; Sat, 5 Jun 2004 17:39:11 -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 i55LdB000818; Sat, 5 Jun 2004 17:39:11 -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 i55Ld0m3003395; Sat, 5 Jun 2004 17:39:01 -0400 Date: Sat, 5 Jun 2004 14:36:49 -0700 From: "David S. Miller" To: Andreas Schwab Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605143649.3fd6c22b.davem@redhat.com> In-Reply-To: References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5642 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: 539 Lines: 15 On Sat, 05 Jun 2004 23:21:53 +0200 Andreas Schwab wrote: > "David S. Miller" writes: > > > This means also that Olaf's patch is broken, when CONFIG_COMPAT is not > > set, MSG_CMSG_COMPAT is zero, thus ~MSG_CMSG_COMPAT is the unexpected > > value all 1's thus breaking the tests for unexpected flags completely. > > ??? Where do you get ~MSG_CMSG_COMPAT from? Olaf's patch, it said: - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) From davem@redhat.com Sat Jun 5 14:41:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:41:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Lftgi017690 for ; Sat, 5 Jun 2004 14:41: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 i55Lfpi5003433; Sat, 5 Jun 2004 17:41:51 -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 i55Lfp001199; Sat, 5 Jun 2004 17:41:51 -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 i55Lfesw003753; Sat, 5 Jun 2004 17:41:40 -0400 Date: Sat, 5 Jun 2004 14:39:29 -0700 From: "David S. Miller" To: Harald Welte Cc: hadi@znyx.com, netdev@oss.sgi.com Subject: Re: small netfilter cleanup Message-Id: <20040605143929.5f0980f6.davem@redhat.com> In-Reply-To: <20040605140104.GD1128@sunbeam.de.gnumonks.org> References: <1086434538.1590.16.camel@jzny.localdomain> <20040605140104.GD1128@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5644 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: 282 Lines: 9 On Sat, 5 Jun 2004 16:01:04 +0200 Harald Welte wrote: > > Attached patches for 2.4.26 and 2.6.6; both should patch > > cleanly against pre 2.4.27 and 2.6.7 > > dave, would you pleae apply the patches to 2.4 an 2.6 ? thanks. Will do sometime this weekend. From davem@redhat.com Sat Jun 5 14:44:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:44:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55LiPgi018013 for ; Sat, 5 Jun 2004 14:44:26 -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 i55LiMi5003841; Sat, 5 Jun 2004 17:44:22 -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 i55LiM001857; Sat, 5 Jun 2004 17:44: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 i55LiBs6004519; Sat, 5 Jun 2004 17:44:11 -0400 Date: Sat, 5 Jun 2004 14:42:00 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: maxk@qualcomm.com, netdev@oss.sgi.com, syrius.ml@no-log.org, jgarzik@pobox.com Subject: Re: PATCH: Re: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post. Message-Id: <20040605144200.7e31f427.davem@redhat.com> In-Reply-To: <1086441896.1592.137.camel@jzny.localdomain> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> <1082719745.1057.27.camel@jzny.localdomain> <1082816083.1054.32.camel@jzny.localdomain> <1083007898.7788.276.camel@localhost> <1084017322.1041.30.camel@jzny.localdomain> <1084209482.758.15.camel@localhost> <1086441896.1592.137.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5645 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: 256 Lines: 8 On 05 Jun 2004 09:24:56 -0400 jamal wrote: > Ok, trivial patch attached. Applies to both latest 2.6 and 2.4 > I will go hunting for more drivers that do this; for now, a good start > here. Applied to both 2.4.x and 2.6.x, thanks Jamal. From olh@suse.de Sat Jun 5 14:55:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:56:04 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Ltfgi018835 for ; Sat, 5 Jun 2004 14:55:42 -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 6835D69F2C5; Sat, 5 Jun 2004 23:17:02 +0200 (CEST) Date: Sat, 5 Jun 2004 23:17:01 +0200 From: Olaf Hering To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-ID: <20040605211701.GD1134@suse.de> References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20040605140153.6c5945a0.davem@redhat.com> 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i55Ltfgi018835 X-archive-position: 5646 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: 482 Lines: 17 On Sat, Jun 05, David S. Miller wrote: > I can't see a reason, can anyone else? If there is no reason, the > right fix is simply to mask it out at the top level, for both > sendmsg and recvmsg. I did it first this way, but the result was a long delay until the dhcp server replied, the patch sent earlier leads to a fast reply. err = sock_recvmsg(sock, &msg_sys, total_len, flags & ~MSG_CMSG_COMPAT); -- USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG From davem@redhat.com Sat Jun 5 14:55:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:56:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Ltugi018850 for ; Sat, 5 Jun 2004 14:55: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 i55Ltti5005760; Sat, 5 Jun 2004 17:55: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 i55Ltt004033; Sat, 5 Jun 2004 17:55:55 -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 i55LtiVq006738; Sat, 5 Jun 2004 17:55:45 -0400 Date: Sat, 5 Jun 2004 14:53:33 -0700 From: "David S. Miller" To: Andreas Schwab Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605145333.11c80173.davem@redhat.com> In-Reply-To: References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> <20040605143649.3fd6c22b.davem@redhat.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5647 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: 8725 Lines: 259 On Sat, 05 Jun 2004 23:47:22 +0200 Andreas Schwab wrote: > > Olaf's patch, it said: > > > > - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) > > + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) > > Yes, and where is the problem? If MSG_CMSG_COMPAT is "ZERO", which it will be if CONFIG_COMPAT is not set, then "~0" is all bits, therefore if any bit (even the ones we want to accept) is set we will return failure. The test ends up amounting to: if (flags & ~0) which is true if any bit is set, that's not what we want. Anyways, I'm going to fix the bug like so: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/05 14:52:04-07:00 davem@nuts.davemloft.net # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/wanrouter/af_wanpipe.c # 2004/06/05 14:51:43-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/netrom/af_netrom.c # 2004/06/05 14:51:43-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/econet/af_econet.c # 2004/06/05 14:51:43-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/decnet/af_decnet.c # 2004/06/05 14:51:43-07:00 davem@nuts.davemloft.net +2 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/x25/af_x25.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +2 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/rose/af_rose.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/packet/af_packet.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/key/af_key.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/irda/af_irda.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +3 -3 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/ipx/af_ipx.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/ax25/af_ax25.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +1 -2 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # net/appletalk/ddp.c # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # # include/linux/socket.h # 2004/06/05 14:51:42-07:00 davem@nuts.davemloft.net +2 -0 # [NET]: Fix bogus msg_flags checks, need to mask out MSG_CMSG_COMPAT. # diff -Nru a/include/linux/socket.h b/include/linux/socket.h --- a/include/linux/socket.h 2004-06-05 14:53:34 -07:00 +++ b/include/linux/socket.h 2004-06-05 14:53:34 -07:00 @@ -241,8 +241,10 @@ #if defined(CONFIG_COMPAT) #define MSG_CMSG_COMPAT 0x80000000 /* This message needs 32 bit fixups */ +#define MSG_FLAGS_USER(X) ((X) & ~MSG_CMSG_COMPAT) #else #define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups */ +#define MSG_FLAGS_USER(X) (X) #endif diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c 2004-06-05 14:53:35 -07:00 +++ b/net/appletalk/ddp.c 2004-06-05 14:53:35 -07:00 @@ -1567,7 +1567,7 @@ struct atalk_route *rt; int err; - if (flags & ~MSG_DONTWAIT) + if (MSG_FLAGS_USER(flags) & ~MSG_DONTWAIT) return -EINVAL; if (len > DDP_MAXSZ) diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c 2004-06-05 14:53:34 -07:00 +++ b/net/ax25/af_ax25.c 2004-06-05 14:53:34 -07:00 @@ -1413,9 +1413,8 @@ size_t size; int lv, err, addr_len = msg->msg_namelen; - if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) { + if (MSG_FLAGS_USER(msg->msg_flags) & ~(MSG_DONTWAIT|MSG_EOR)) return -EINVAL; - } lock_sock(sk); ax25 = ax25_sk(sk); diff -Nru a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c --- a/net/decnet/af_decnet.c 2004-06-05 14:53:34 -07:00 +++ b/net/decnet/af_decnet.c 2004-06-05 14:53:34 -07:00 @@ -1905,7 +1905,8 @@ unsigned char fctype; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); - if (flags & ~(MSG_TRYHARD|MSG_OOB|MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|MSG_MORE)) + if (MSG_FLAGS_USER(flags) & + ~(MSG_TRYHARD|MSG_OOB|MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|MSG_MORE)) return -EOPNOTSUPP; if (addr_len && (addr_len != sizeof(struct sockaddr_dn))) diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c 2004-06-05 14:53:34 -07:00 +++ b/net/econet/af_econet.c 2004-06-05 14:53:34 -07:00 @@ -274,7 +274,7 @@ * Check the flags. */ - if (msg->msg_flags&~MSG_DONTWAIT) + if (MSG_FLAGS_USER(msg->msg_flags) & ~MSG_DONTWAIT) return(-EINVAL); /* diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c --- a/net/ipx/af_ipx.c 2004-06-05 14:53:34 -07:00 +++ b/net/ipx/af_ipx.c 2004-06-05 14:53:34 -07:00 @@ -1695,7 +1695,7 @@ /* Socket gets bound below anyway */ /* if (sk->sk_zapped) return -EIO; */ /* Socket not bound */ - if (flags & ~MSG_DONTWAIT) + if (MSG_FLAGS_USER(flags) & ~MSG_DONTWAIT) goto out; /* Max possible packet size limited by 16 bit pktsize in header */ diff -Nru a/net/irda/af_irda.c b/net/irda/af_irda.c --- a/net/irda/af_irda.c 2004-06-05 14:53:34 -07:00 +++ b/net/irda/af_irda.c 2004-06-05 14:53:34 -07:00 @@ -1269,7 +1269,7 @@ IRDA_DEBUG(4, "%s(), len=%d\n", __FUNCTION__, len); /* Note : socket.c set MSG_EOR on SEQPACKET sockets */ - if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_EOR)) + if (MSG_FLAGS_USER(msg->msg_flags) & ~(MSG_DONTWAIT | MSG_EOR)) return -EINVAL; if (sk->sk_shutdown & SEND_SHUTDOWN) { @@ -1521,7 +1521,7 @@ IRDA_DEBUG(4, "%s(), len=%d\n", __FUNCTION__, len); - if (msg->msg_flags & ~MSG_DONTWAIT) + if (MSG_FLAGS_USER(msg->msg_flags) & ~MSG_DONTWAIT) return -EINVAL; if (sk->sk_shutdown & SEND_SHUTDOWN) { @@ -1593,7 +1593,7 @@ IRDA_DEBUG(4, "%s(), len=%d\n", __FUNCTION__, len); - if (msg->msg_flags & ~MSG_DONTWAIT) + if (MSG_FLAGS_USER(msg->msg_flags) & ~MSG_DONTWAIT) return -EINVAL; if (sk->sk_shutdown & SEND_SHUTDOWN) { diff -Nru a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c 2004-06-05 14:53:34 -07:00 +++ b/net/key/af_key.c 2004-06-05 14:53:34 -07:00 @@ -2726,7 +2726,7 @@ int copied, err; err = -EINVAL; - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) + if (MSG_FLAGS_USER(flags) & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) goto out; msg->msg_namelen = 0; diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c 2004-06-05 14:53:34 -07:00 +++ b/net/netrom/af_netrom.c 2004-06-05 14:53:34 -07:00 @@ -1021,7 +1021,7 @@ unsigned char *asmptr; int size; - if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) + if (MSG_FLAGS_USER(msg->msg_flags) & ~(MSG_DONTWAIT|MSG_EOR)) return -EINVAL; lock_sock(sk); diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c 2004-06-05 14:53:34 -07:00 +++ b/net/packet/af_packet.c 2004-06-05 14:53:34 -07:00 @@ -1037,7 +1037,7 @@ int copied, err; err = -EINVAL; - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) + if (MSG_FLAGS_USER(flags) & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) goto out; #if 0 diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c 2004-06-05 14:53:34 -07:00 +++ b/net/rose/af_rose.c 2004-06-05 14:53:34 -07:00 @@ -1021,7 +1021,7 @@ unsigned char *asmptr; int n, size, qbit = 0; - if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) + if (MSG_FLAGS_USER(msg->msg_flags) & ~(MSG_DONTWAIT|MSG_EOR)) return -EINVAL; if (sk->sk_zapped) diff -Nru a/net/wanrouter/af_wanpipe.c b/net/wanrouter/af_wanpipe.c --- a/net/wanrouter/af_wanpipe.c 2004-06-05 14:53:34 -07:00 +++ b/net/wanrouter/af_wanpipe.c 2004-06-05 14:53:35 -07:00 @@ -552,7 +552,7 @@ if (sk->sk_state != WANSOCK_CONNECTED) return -ENOTCONN; - if (msg->msg_flags&~MSG_DONTWAIT) + if (MSG_FLAGS_USER(msg->msg_flags) & ~MSG_DONTWAIT) return(-EINVAL); /* it was <=, now one can send diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c 2004-06-05 14:53:34 -07:00 +++ b/net/x25/af_x25.c 2004-06-05 14:53:34 -07:00 @@ -922,7 +922,8 @@ size_t size; int qbit = 0, rc = -EINVAL; - if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_OOB | MSG_EOR)) + if (MSG_FLAGS_USER(msg->msg_flags) & + ~(MSG_DONTWAIT | MSG_OOB | MSG_EOR)) goto out; /* we currently don't support segmented records at the user interface */ From olh@suse.de Sat Jun 5 14:57:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:57:26 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Lv3gi019364 for ; Sat, 5 Jun 2004 14:57:04 -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 A1B6169F288; Sat, 5 Jun 2004 23:14:09 +0200 (CEST) Date: Sat, 5 Jun 2004 23:14:09 +0200 From: Olaf Hering To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: Olaf Hering Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-ID: <20040605211409.GC1134@suse.de> References: <20040605204334.GA1134@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20040605204334.GA1134@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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i55Lv3gi019364 X-archive-position: 5648 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: 532 Lines: 30 On Sat, Jun 05, Olaf Hering wrote: > > packet_recvmsg() gets the flags from the compat_sys_socketcall(), but it > does not check for the active MSG_CMSG_COMPAT bit. As a result, it > returns -EINVAL and makes the user rather unhappy possible related bugs are in: ipx_sendmsg pfkey_recvmsg x25_sendmsg ax25_sendmsg irda_sendmsg irda_sendmsg_dgram irda_sendmsg_ultra rose_sendmsg atalk_sendmsg dn_recvmsg dn_sendmsg econet_sendmsg wanpipe_sendmsg nr_sendmsg -- USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG From schwab@suse.de Sat Jun 5 14:58:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 14:58:26 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55Lw3gi019754 for ; Sat, 5 Jun 2004 14:58:03 -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 D67DE69C371; Sat, 5 Jun 2004 23:21:53 +0200 (CEST) To: "David S. Miller" Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> From: Andreas Schwab X-Yow: It's the RINSE CYCLE!! They've ALL IGNORED the RINSE CYCLE!! Date: Sat, 05 Jun 2004 23:21:53 +0200 In-Reply-To: <20040605140544.0de4034d.davem@redhat.com> (David S. Miller's message of "Sat, 5 Jun 2004 14:05:44 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) 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 i55Lw3gi019754 X-archive-position: 5649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schwab@suse.de Precedence: bulk X-list: netdev Content-Length: 538 Lines: 16 "David S. Miller" writes: > This means also that Olaf's patch is broken, when CONFIG_COMPAT is not > set, MSG_CMSG_COMPAT is zero, thus ~MSG_CMSG_COMPAT is the unexpected > value all 1's thus breaking the tests for unexpected flags completely. ??? Where do you get ~MSG_CMSG_COMPAT from? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Maxfeldstrae 5, 90409 Nrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From schwab@suse.de Sat Jun 5 15:06:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 15:06:09 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55M65gi020177 for ; Sat, 5 Jun 2004 15:06:06 -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 848B669F705; Sun, 6 Jun 2004 00:05:59 +0200 (CEST) To: "David S. Miller" Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> <20040605143649.3fd6c22b.davem@redhat.com> <20040605145333.11c80173.davem@redhat.com> From: Andreas Schwab X-Yow: I need to discuss BUY-BACK PROVISIONS with at least six studio SLEAZEBALLS!! Date: Sun, 06 Jun 2004 00:05:58 +0200 In-Reply-To: <20040605145333.11c80173.davem@redhat.com> (David S. Miller's message of "Sat, 5 Jun 2004 14:53:33 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) 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 i55M65gi020177 X-archive-position: 5650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schwab@suse.de Precedence: bulk X-list: netdev Content-Length: 1786 Lines: 60 "David S. Miller" writes: > On Sat, 05 Jun 2004 23:47:22 +0200 > Andreas Schwab wrote: > >> > Olaf's patch, it said: >> > >> > - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) >> > + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) >> >> Yes, and where is the problem? > > If MSG_CMSG_COMPAT is "ZERO", which it will be if CONFIG_COMPAT is > not set, then "~0" is all bits, therefore if any bit (even the ones > we want to accept) is set we will return failure. The test ends > up amounting to: > > if (flags & ~0) > > which is true if any bit is set, that's not what we want. Can you say DeMorgan? > diff -Nru a/include/linux/socket.h b/include/linux/socket.h > --- a/include/linux/socket.h 2004-06-05 14:53:34 -07:00 > +++ b/include/linux/socket.h 2004-06-05 14:53:34 -07:00 > @@ -241,8 +241,10 @@ > > #if defined(CONFIG_COMPAT) > #define MSG_CMSG_COMPAT 0x80000000 /* This message needs 32 bit fixups */ > +#define MSG_FLAGS_USER(X) ((X) & ~MSG_CMSG_COMPAT) > #else > #define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups */ > +#define MSG_FLAGS_USER(X) (X) > #endif > > > diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c > --- a/net/appletalk/ddp.c 2004-06-05 14:53:35 -07:00 > +++ b/net/appletalk/ddp.c 2004-06-05 14:53:35 -07:00 > @@ -1567,7 +1567,7 @@ > struct atalk_route *rt; > int err; > > - if (flags & ~MSG_DONTWAIT) > + if (MSG_FLAGS_USER(flags) & ~MSG_DONTWAIT) > return -EINVAL; > > if (len > DDP_MAXSZ) This is exactly equivalent to Olaf's version. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Maxfeldstrae 5, 90409 Nrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From khc@pm.waw.pl Sat Jun 5 15:18:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 15:18:20 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55MIFgi020641 for ; Sat, 5 Jun 2004 15:18:16 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id A1183358; Sun, 6 Jun 2004 00:18:09 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 99AF6302D4; Sat, 5 Jun 2004 22:43:32 +0200 (CEST) To: Mikael Pettersson Cc: jgarzik@pobox.com, dctucker@hotmail.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: PROBLEM: network driver causes kernel panic References: <200406051215.i55CF4hH004189@harpo.it.uu.se> From: Krzysztof Halasa Date: Sat, 05 Jun 2004 22:43:32 +0200 In-Reply-To: <200406051215.i55CF4hH004189@harpo.it.uu.se> (Mikael Pettersson's message of "Sat, 5 Jun 2004 14:15:04 +0200 (MEST)") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5651 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 Content-Length: 410 Lines: 12 Mikael Pettersson writes: > Booting 2.6.7-rc1 with the de2104x driver built-in and eth0 > disconnected from the LAN leads to the following oops about > a second after INIT tried to ifup eth0: > > eth0: timeout expired stopping DMA > kernel BUG in de_set_media at drivers/net/tulip/de2104x.c:919! Same here, i386, SMC EtherPower^2 (dual 21040 + 21050 PCI bridge). -- Krzysztof Halasa, B*FH From schwab@suse.de Sat Jun 5 15:30:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 15:30:14 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55MU1gi021123 for ; Sat, 5 Jun 2004 15:30:02 -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 92B9B69F5B9; Sat, 5 Jun 2004 23:47:23 +0200 (CEST) To: "David S. Miller" Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> <20040605143649.3fd6c22b.davem@redhat.com> From: Andreas Schwab X-Yow: I'm dressing up in an ill-fitting IVY-LEAGUE SUIT!! Too late... Date: Sat, 05 Jun 2004 23:47:22 +0200 In-Reply-To: <20040605143649.3fd6c22b.davem@redhat.com> (David S. Miller's message of "Sat, 5 Jun 2004 14:36:49 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) 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 i55MU1gi021123 X-archive-position: 5652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schwab@suse.de Precedence: bulk X-list: netdev Content-Length: 866 Lines: 28 "David S. Miller" writes: > On Sat, 05 Jun 2004 23:21:53 +0200 > Andreas Schwab wrote: > >> "David S. Miller" writes: >> >> > This means also that Olaf's patch is broken, when CONFIG_COMPAT is not >> > set, MSG_CMSG_COMPAT is zero, thus ~MSG_CMSG_COMPAT is the unexpected >> > value all 1's thus breaking the tests for unexpected flags completely. >> >> ??? Where do you get ~MSG_CMSG_COMPAT from? > > Olaf's patch, it said: > > - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) > + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) Yes, and where is the problem? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Maxfeldstrae 5, 90409 Nrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From davem@redhat.com Sat Jun 5 15:32:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 15:32:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55MWDgi021453 for ; Sat, 5 Jun 2004 15:32:13 -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 i55MWCi5010968; Sat, 5 Jun 2004 18:32: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 i55MWC010512; Sat, 5 Jun 2004 18:32: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 i55MW135013713; Sat, 5 Jun 2004 18:32:01 -0400 Date: Sat, 5 Jun 2004 15:29:49 -0700 From: "David S. Miller" To: Andreas Schwab Cc: olh@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605152949.785a9e41.davem@redhat.com> In-Reply-To: References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> <20040605143649.3fd6c22b.davem@redhat.com> <20040605145333.11c80173.davem@redhat.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5653 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: 172 Lines: 7 On Sun, 06 Jun 2004 00:05:58 +0200 Andreas Schwab wrote: > Can you say DeMorgan? Sorry, thought I had put enough caffeine in my system. Aparently not :) From olh@suse.de Sat Jun 5 15:37:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 15:37:36 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55MbUgi021863 for ; Sat, 5 Jun 2004 15:37: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 9136269F966; Sun, 6 Jun 2004 00:37:24 +0200 (CEST) Date: Sun, 6 Jun 2004 00:37:23 +0200 From: Olaf Hering To: "David S. Miller" Cc: Andreas Schwab , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-ID: <20040605223723.GA32360@suse.de> References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> <20040605143649.3fd6c22b.davem@redhat.com> <20040605145333.11c80173.davem@redhat.com> <20040605152949.785a9e41.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20040605152949.785a9e41.davem@redhat.com> 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i55MbUgi021863 X-archive-position: 5654 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: 7576 Lines: 185 On Sat, Jun 05, David S. Miller wrote: > On Sun, 06 Jun 2004 00:05:58 +0200 > Andreas Schwab wrote: > > > Can you say DeMorgan? > > Sorry, thought I had put enough caffeine in my system. > Aparently not :) Lets agree on this version. diff -p -purN linux-2.6.7-rc2-bk5.orig/net/appletalk/ddp.c linux-2.6.7-rc2-bk5/net/appletalk/ddp.c --- linux-2.6.7-rc2-bk5.orig/net/appletalk/ddp.c 2004-06-05 09:34:47.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/appletalk/ddp.c 2004-06-06 00:21:48.000000000 +0200 @@ -1567,7 +1567,7 @@ static int atalk_sendmsg(struct kiocb *i struct atalk_route *rt; int err; - if (flags & ~MSG_DONTWAIT) + if (flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) return -EINVAL; if (len > DDP_MAXSZ) diff -p -purN linux-2.6.7-rc2-bk5.orig/net/ax25/af_ax25.c linux-2.6.7-rc2-bk5/net/ax25/af_ax25.c --- linux-2.6.7-rc2-bk5.orig/net/ax25/af_ax25.c 2004-06-05 09:34:47.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/ax25/af_ax25.c 2004-06-06 00:23:18.000000000 +0200 @@ -1413,9 +1413,8 @@ static int ax25_sendmsg(struct kiocb *io size_t size; int lv, err, addr_len = msg->msg_namelen; - if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) { + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_CMSG_COMPAT)) return -EINVAL; - } lock_sock(sk); ax25 = ax25_sk(sk); diff -p -purN linux-2.6.7-rc2-bk5.orig/net/decnet/af_decnet.c linux-2.6.7-rc2-bk5/net/decnet/af_decnet.c --- linux-2.6.7-rc2-bk5.orig/net/decnet/af_decnet.c 2004-06-05 09:34:47.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/decnet/af_decnet.c 2004-06-06 00:23:01.000000000 +0200 @@ -1905,7 +1905,7 @@ static int dn_sendmsg(struct kiocb *iocb unsigned char fctype; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); - if (flags & ~(MSG_TRYHARD|MSG_OOB|MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|MSG_MORE)) + if (flags & ~(MSG_TRYHARD|MSG_OOB|MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|MSG_MORE|MSG_CMSG_COMPAT)) return -EOPNOTSUPP; if (addr_len && (addr_len != sizeof(struct sockaddr_dn))) diff -p -purN linux-2.6.7-rc2-bk5.orig/net/econet/af_econet.c linux-2.6.7-rc2-bk5/net/econet/af_econet.c --- linux-2.6.7-rc2-bk5.orig/net/econet/af_econet.c 2004-06-05 09:34:47.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/econet/af_econet.c 2004-06-06 00:24:19.000000000 +0200 @@ -274,8 +274,8 @@ static int econet_sendmsg(struct kiocb * * Check the flags. */ - if (msg->msg_flags&~MSG_DONTWAIT) - return(-EINVAL); + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) + return -EINVAL; /* * Get and verify the address. diff -p -purN linux-2.6.7-rc2-bk5.orig/net/ipx/af_ipx.c linux-2.6.7-rc2-bk5/net/ipx/af_ipx.c --- linux-2.6.7-rc2-bk5.orig/net/ipx/af_ipx.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/ipx/af_ipx.c 2004-06-06 00:24:54.000000000 +0200 @@ -1695,7 +1695,7 @@ static int ipx_sendmsg(struct kiocb *ioc /* Socket gets bound below anyway */ /* if (sk->sk_zapped) return -EIO; */ /* Socket not bound */ - if (flags & ~MSG_DONTWAIT) + if (flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) goto out; /* Max possible packet size limited by 16 bit pktsize in header */ diff -p -purN linux-2.6.7-rc2-bk5.orig/net/irda/af_irda.c linux-2.6.7-rc2-bk5/net/irda/af_irda.c --- linux-2.6.7-rc2-bk5.orig/net/irda/af_irda.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/irda/af_irda.c 2004-06-06 00:27:55.000000000 +0200 @@ -1269,7 +1269,7 @@ static int irda_sendmsg(struct kiocb *io IRDA_DEBUG(4, "%s(), len=%d\n", __FUNCTION__, len); /* Note : socket.c set MSG_EOR on SEQPACKET sockets */ - if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_EOR)) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_CMSG_COMPAT)) return -EINVAL; if (sk->sk_shutdown & SEND_SHUTDOWN) { @@ -1521,7 +1521,7 @@ static int irda_sendmsg_dgram(struct kio IRDA_DEBUG(4, "%s(), len=%d\n", __FUNCTION__, len); - if (msg->msg_flags & ~MSG_DONTWAIT) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) return -EINVAL; if (sk->sk_shutdown & SEND_SHUTDOWN) { @@ -1593,7 +1593,7 @@ static int irda_sendmsg_ultra(struct kio IRDA_DEBUG(4, "%s(), len=%d\n", __FUNCTION__, len); - if (msg->msg_flags & ~MSG_DONTWAIT) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) return -EINVAL; if (sk->sk_shutdown & SEND_SHUTDOWN) { diff -p -purN linux-2.6.7-rc2-bk5.orig/net/key/af_key.c linux-2.6.7-rc2-bk5/net/key/af_key.c --- linux-2.6.7-rc2-bk5.orig/net/key/af_key.c 2004-06-05 09:31:46.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/key/af_key.c 2004-06-06 00:28:49.000000000 +0200 @@ -2726,7 +2726,7 @@ static int pfkey_recvmsg(struct kiocb *k int copied, err; err = -EINVAL; - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) goto out; msg->msg_namelen = 0; diff -p -purN linux-2.6.7-rc2-bk5.orig/net/netrom/af_netrom.c linux-2.6.7-rc2-bk5/net/netrom/af_netrom.c --- linux-2.6.7-rc2-bk5.orig/net/netrom/af_netrom.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/netrom/af_netrom.c 2004-06-06 00:29:00.000000000 +0200 @@ -1021,7 +1021,7 @@ static int nr_sendmsg(struct kiocb *iocb unsigned char *asmptr; int size; - if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_CMSG_COMPAT)) return -EINVAL; lock_sock(sk); diff -p -purN linux-2.6.7-rc2-bk5.orig/net/packet/af_packet.c linux-2.6.7-rc2-bk5/net/packet/af_packet.c --- linux-2.6.7-rc2-bk5.orig/net/packet/af_packet.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/packet/af_packet.c 2004-06-05 22:32:16.000000000 +0200 @@ -1037,7 +1037,7 @@ static int packet_recvmsg(struct kiocb * int copied, err; err = -EINVAL; - if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC)) + if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT)) goto out; #if 0 diff -p -purN linux-2.6.7-rc2-bk5.orig/net/rose/af_rose.c linux-2.6.7-rc2-bk5/net/rose/af_rose.c --- linux-2.6.7-rc2-bk5.orig/net/rose/af_rose.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/rose/af_rose.c 2004-06-06 00:29:29.000000000 +0200 @@ -1021,7 +1021,7 @@ static int rose_sendmsg(struct kiocb *io unsigned char *asmptr; int n, size, qbit = 0; - if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_CMSG_COMPAT)) return -EINVAL; if (sk->sk_zapped) diff -p -purN linux-2.6.7-rc2-bk5.orig/net/wanrouter/af_wanpipe.c linux-2.6.7-rc2-bk5/net/wanrouter/af_wanpipe.c --- linux-2.6.7-rc2-bk5.orig/net/wanrouter/af_wanpipe.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/wanrouter/af_wanpipe.c 2004-06-06 00:29:51.000000000 +0200 @@ -552,7 +552,7 @@ static int wanpipe_sendmsg(struct kiocb if (sk->sk_state != WANSOCK_CONNECTED) return -ENOTCONN; - if (msg->msg_flags&~MSG_DONTWAIT) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) return(-EINVAL); /* it was <=, now one can send diff -p -purN linux-2.6.7-rc2-bk5.orig/net/x25/af_x25.c linux-2.6.7-rc2-bk5/net/x25/af_x25.c --- linux-2.6.7-rc2-bk5.orig/net/x25/af_x25.c 2004-06-05 09:34:48.000000000 +0200 +++ linux-2.6.7-rc2-bk5/net/x25/af_x25.c 2004-06-06 00:30:20.000000000 +0200 @@ -922,7 +922,7 @@ static int x25_sendmsg(struct kiocb *ioc size_t size; int qbit = 0, rc = -EINVAL; - if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_OOB | MSG_EOR)) + if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_OOB|MSG_EOR|MSG_CMSG_COMPAT)) goto out; /* we currently don't support segmented records at the user interface */ -- USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG From davem@redhat.com Sat Jun 5 15:57:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 15:57:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i55MvRgi022465 for ; Sat, 5 Jun 2004 15:57: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 i55MvQi5014432; Sat, 5 Jun 2004 18:57:26 -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 i55MvQ014749; Sat, 5 Jun 2004 18:57: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 i55MvFGi018186; Sat, 5 Jun 2004 18:57:15 -0400 Date: Sat, 5 Jun 2004 15:55:02 -0700 From: "David S. Miller" To: Olaf Hering Cc: schwab@suse.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] compat bug in sys_recvmsg, MSG_CMSG_COMPAT check missing Message-Id: <20040605155502.3afe43cd.davem@redhat.com> In-Reply-To: <20040605223723.GA32360@suse.de> References: <20040605204334.GA1134@suse.de> <20040605140153.6c5945a0.davem@redhat.com> <20040605140544.0de4034d.davem@redhat.com> <20040605143649.3fd6c22b.davem@redhat.com> <20040605145333.11c80173.davem@redhat.com> <20040605152949.785a9e41.davem@redhat.com> <20040605223723.GA32360@suse.de> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5655 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: 211 Lines: 11 On Sun, 6 Jun 2004 00:37:23 +0200 Olaf Hering wrote: > > Sorry, thought I had put enough caffeine in my system. > > Aparently not :) > > Lets agree on this version. Yep, patch applied. Thanks. From jketreno@linux.jf.intel.com Sat Jun 5 19:45:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jun 2004 19:45:33 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i562jRgi029990 for ; Sat, 5 Jun 2004 19:45:27 -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 i53HBk5b001467; Thu, 3 Jun 2004 17:11:58 GMT Received: from linux.jf.intel.com ([134.134.19.82]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with ESMTP id i540CsAQ028153; Fri, 4 Jun 2004 00:12:56 GMT Message-ID: <40BFBE56.8030005@linux.jf.intel.com> Date: Thu, 03 Jun 2004 19:12:06 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev Subject: Re: wireless-2.6 queue opened References: <40BE9ED8.9020505@pobox.com> In-Reply-To: <40BE9ED8.9020505@pobox.com> 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: 5656 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.jf.intel.com Precedence: bulk X-list: netdev Content-Length: 3372 Lines: 77 I thought I had replied to this, but I don't see it in my sent, drafts, or on the list... so, I'll recompose and send again. Jeff Garzik wrote: > It's high time that Linux get a serious effort going on a generic > 802.11 stack, as it seems we are in danger of having every new > wireless driver invent one if we do not. Agreed. > Given that there are at least 3 complete wireless stacks (or > thereabouts) floating about for Linux, I picked one that I felt had > the best chance of being _evolved_ into a nice, clean, generic > wireless stack: HostAP. This is the path that ipw2100 has been following; we have taken a snapshot of the Host AP code and have generalized the Tx/Rx stacks to remove all HW specific fields and structures so we can use them for the ipw2100 and (eventually) the ipw2200 project. We currently have a HW independent stack that should work for any underlying card that can Tx/Rx 802.11 data frames. This stack is based on Host AP 0.1.3 (Pedro Ramalhais has since written a patch for ipw2100 that will update it to using the Host AP CVS) The stack we have is not as complete as the original Host AP project -- portions of the code (specifically those aspects which I can't test or leverage w/ the HW I have) have been wrapped in #ifdef/#endif blocks (pretty much everything dealing with master mode). As we've been trying to track down some ipw2100 project defects we've been liberal in throwing some ipw2100 specific checks into the ieee80211_* files, but those are easily removed. Also a result of that defect tracking there is some code in those files that just needs to be cleaned up/removed. > My general hope (plan?) is that generic wireless code can be arrived > at without horribly intrusive changes that require a 2.7 kernel. > wireless-2.6 is targetted for eventual merging, but it won't be > submitted anytime soon. Performance optimizations for wireless may be a bit more intrusive, but are not required (AFAIK) to get a generic stack with performance and features equivelant to what is currently enabled by the various drivers available. > BTW to Intel Centrino folks -- I would like to merge the current (open > source) Centrino driver into wireless-2.6 as well, to get it more > exposure, and also to ensure that it uses whatever generic 802.11 code > happens to appear... I would like to get a couple stability issues resolved before we incorporate the ipw2100 driver into the wireless-2.6 set. For those that are curious, the current work plan for the ipw2100 is (roughly): 0) Fix fragmentation in the current ieee80211_* Tx/Rx stack 1) Generalize the management frame handling (as much as is currently required) into ieee80211_* 2) Extract the ieee80211_* code so that it can be compiled into the kernel separate from ipw2100 (either as a module or static) 3) Create a patchset for the wireless extension interface to support what's needed to configure algos and keys (based in part on what is done in Host AP and other drivers). Also provide a patchset for the user space tools. Hopefully that will kick off lots of discussion :) During all of the above we will also be working to fix existing stability and feature issues. Main issues here deal with a data corruption issue during C3 processor transitions as well as random stalling of SSL connections. James From herbert@gondor.apana.org.au Sun Jun 6 01:42:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 01:42:26 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i568g9gi012026 for ; Sun, 6 Jun 2004 01:42: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 1BWtDf-0003Z4-00; Sun, 06 Jun 2004 18:41:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BWtDU-0001PT-00; Sun, 06 Jun 2004 18:41:20 +1000 Date: Sun, 6 Jun 2004 18:41:19 +1000 To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: 5/x: [NETDRV] Move register_netdev into probe function Message-ID: <20040606084119.GA5399@gondor.apana.org.au> References: <20040313025859.GA8186@gondor.apana.org.au> <405C294D.5040508@pobox.com> <20040520111937.GA21804@gondor.apana.org.au> <20040522074435.GA9628@gondor.apana.org.au> <20040529084109.GA13032@gondor.apana.org.au> <40BE3778.1020404@pobox.com> <20040605052737.GA27406@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20040605052737.GA27406@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5657 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: 22010 Lines: 909 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jun 05, 2004 at 03:27:37PM +1000, herbert wrote: > > So in its place I present the following patch that merges duplicate > register_netdev calls by moving them to the probe function. Here is the patch to move register_netdev into the probe function for the remaining modules. This allows us to print the information that the driver wants to after the device has been registered. 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 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff -Nru a/drivers/net/3c501.c b/drivers/net/3c501.c --- a/drivers/net/3c501.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/3c501.c 2004-06-06 18:38:44 +10:00 @@ -189,12 +189,7 @@ } if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - release_region(dev->base_addr, EL1_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -220,6 +215,7 @@ unsigned char station_addr[6]; int autoirq = 0; int i; + int err; /* * Reserve I/O resource for exclusive use by this driver @@ -321,7 +317,11 @@ dev->get_stats = &el1_get_stats; dev->set_multicast_list = &set_multicast_list; dev->ethtool_ops = &netdev_ethtool_ops; - return 0; + + err = register_netdev(dev); + if (err) + release_region(ioaddr, EL1_IO_EXTENT); + return err; } /** diff -Nru a/drivers/net/3c507.c b/drivers/net/3c507.c --- a/drivers/net/3c507.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/3c507.c 2004-06-06 18:38:44 +10:00 @@ -341,13 +341,7 @@ 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, EL16_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -453,7 +447,13 @@ dev->watchdog_timeo = TX_TIMEOUT; dev->ethtool_ops = &netdev_ethtool_ops; dev->flags &= ~IFF_MULTICAST; /* Multicast doesn't work */ + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + free_irq(irq, dev); out: release_region(ioaddr, EL16_IO_EXTENT); return retval; diff -Nru a/drivers/net/3c527.c b/drivers/net/3c527.c --- a/drivers/net/3c527.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/3c527.c 2004-06-06 18:38:44 +10:00 @@ -212,7 +212,7 @@ /* Index to functions, as function prototypes. */ -static int mc32_probe1(struct net_device *dev, int ioaddr); +static int mc32_probe1(struct net_device *dev, int ioaddr, char *name); static int mc32_command(struct net_device *dev, u16 cmd, void *data, int len); static int mc32_open(struct net_device *dev); static void mc32_timeout(struct net_device *dev); @@ -266,25 +266,16 @@ Autodetecting MCA cards is extremely simple. Just search for the card. */ + err = -ENODEV; for(i = 0; (mc32_adapters[i].name != NULL); i++) { current_mca_slot = mca_find_unused_adapter(mc32_adapters[i].id, 0); if(current_mca_slot != MCA_NOTFOUND) { - if(!mc32_probe1(dev, current_mca_slot)) - { - mca_set_adapter_name(current_mca_slot, - mc32_adapters[i].name); - mca_mark_as_used(current_mca_slot); - err = register_netdev(dev); - if (err) { - cleanup_card(dev); - free_netdev(dev); - dev = ERR_PTR(err); - } + err = mc32_probe1(dev, current_mca_slot, + mc32_adapters[i].name); + if (!err) return dev; - } - } } free_netdev(dev); @@ -295,6 +286,7 @@ * mc32_probe1 - Check a given slot for a board and test the card * @dev: Device structure to fill in * @slot: The MCA bus slot being used by this card + * @name: Descriptive name of device * * Decode the slot data and configure the card structures. Having done this we * can reset the card and configure it. The card does a full self test cycle @@ -302,7 +294,7 @@ * failure case or some addresses we use to find the board internals. */ -static int __init mc32_probe1(struct net_device *dev, int slot) +static int __init mc32_probe1(struct net_device *dev, int slot, char *name) { static unsigned version_printed; int i, err; @@ -530,8 +522,16 @@ dev->watchdog_timeo = HZ*5; /* Board does all the work */ dev->ethtool_ops = &netdev_ethtool_ops; + mca_set_adapter_name(slot, name); + mca_mark_as_used(slot); + err = register_netdev(dev); + if (err) + goto err_exit_mca; return 0; +err_exit_mca: + mca_mark_as_unused(slot); + mca_set_adapter_name(slot, NULL); err_exit_irq: free_irq(dev->irq, dev); err_exit_ports: diff -Nru a/drivers/net/apne.c b/drivers/net/apne.c --- a/drivers/net/apne.c 2004-06-06 18:38:45 +10:00 +++ b/drivers/net/apne.c 2004-06-06 18:38:45 +10:00 @@ -181,21 +181,13 @@ free_netdev(dev); return ERR_PTR(err); } - err = register_netdev(dev); - if (!err) - return dev; - - pcmcia_disable_irq(); - free_irq(IRQ_AMIGA_PORTS, dev); - pcmcia_reset(); - release_region(IOBASE, 0x20); - free_netdev(dev); - return ERR_PTR(err); + return dev; } static int __init apne_probe1(struct net_device *dev, int ioaddr) { int i; + int err; unsigned char SA_prom[32]; int wordlength = 2; const char *name = NULL; @@ -345,7 +337,14 @@ apne_owned = 1; - return 0; + err = register_netdev(dev); + if (err) { + pcmcia_disable_irq(); + free_irq(IRQ_AMIGA_PORTS, dev); + pcmcia_reset(); + } + + return err; } static int diff -Nru a/drivers/net/at1700.c b/drivers/net/at1700.c --- a/drivers/net/at1700.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/at1700.c 2004-06-06 18:38:44 +10:00 @@ -295,12 +295,7 @@ } 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); @@ -551,8 +546,13 @@ goto err_mca; } + ret = register_netdev(dev); + if (ret) + goto err_irq; return 0; +err_irq: + free_irq(dev->irq, NULL); err_mca: #ifdef CONFIG_MCA if (slot >= 0) diff -Nru a/drivers/net/atarilance.c b/drivers/net/atarilance.c --- a/drivers/net/atarilance.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/atarilance.c 2004-06-06 18:38:44 +10:00 @@ -395,11 +395,7 @@ for( i = 0; i < N_LANCE_ADDR; ++i ) { if (lance_probe1( dev, &lance_addr_list[i] )) { found = 1; - err = register_netdev(dev); - if (!err) - return dev; - free_irq(dev->irq, dev); - break; + return dev; } } free_netdev(dev); @@ -647,6 +643,10 @@ memset( &lp->stats, 0, sizeof(lp->stats) ); + if (register_netdev(dev)) { + free_irq(dev->irq, dev); + return 0; + } return( 1 ); } diff -Nru a/drivers/net/bagetlance.c b/drivers/net/bagetlance.c --- a/drivers/net/bagetlance.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/bagetlance.c 2004-06-06 18:38:44 +10:00 @@ -491,12 +491,7 @@ } if (!found) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - free_irq(dev->irq, dev); out: free_netdev(dev); return ERR_PTR(err); @@ -730,6 +725,10 @@ memset( &lp->stats, 0, sizeof(lp->stats) ); + if (register_netdev(dev)) { + free_irq(dev->irq, dev); + return 0; + } return( 1 ); } diff -Nru a/drivers/net/ewrk3.c b/drivers/net/ewrk3.c --- a/drivers/net/ewrk3.c 2004-06-06 18:38:45 +10:00 +++ b/drivers/net/ewrk3.c 2004-06-06 18:38:45 +10:00 @@ -378,14 +378,6 @@ err = isa_probe(dev, iobase); if (err != 0) err = eisa_probe(dev, iobase); - - if (err) - return err; - - err = register_netdev(dev); - if (err) - release_region(dev->base_addr, EWRK3_TOTAL_SIZE); - return err; } @@ -615,7 +607,7 @@ dev->mem_start = 0; - return 0; + return register_netdev(dev); } diff -Nru a/drivers/net/fec.c b/drivers/net/fec.c --- a/drivers/net/fec.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/fec.c 2004-06-06 18:38:44 +10:00 @@ -1789,7 +1789,9 @@ mii_queue(dev, mk_mii_read(MII_REG_PHYIR1), mii_discover_phy); found++; - return 0; + + /* XXX: missing cleanup here */ + return register_netdev(dev); } /* This function is called to start or restart the FEC during a link @@ -1960,11 +1962,6 @@ return err; } - if (register_netdev(dev) != 0) { - /* XXX: missing cleanup here */ - free_netdev(dev); - return -EIO; - } fec_dev = dev; return(0); } diff -Nru a/drivers/net/fmv18x.c b/drivers/net/fmv18x.c --- a/drivers/net/fmv18x.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/fmv18x.c 2004-06-06 18:38:44 +10:00 @@ -163,13 +163,7 @@ } 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, FMV18X_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -305,6 +299,10 @@ dev->watchdog_timeo = HZ/10; dev->get_stats = net_get_stats; dev->set_multicast_list = set_multicast_list; + + retval = register_netdev(dev); + if (retval) + goto out_irq; return 0; out_irq: diff -Nru a/drivers/net/hplance.c b/drivers/net/hplance.c --- a/drivers/net/hplance.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/hplance.c 2004-06-06 18:38:44 +10:00 @@ -50,7 +50,7 @@ * plus board-specific init, open and close actions. * Oh, and we need to tell the generic code how to read and write LANCE registers... */ -static void hplance_init(struct net_device *dev, int scode); +static int hplance_init(struct net_device *dev, int scode); static int hplance_open(struct net_device *dev); static int hplance_close(struct net_device *dev); static void hplance_writerap(void *priv, unsigned short value); @@ -95,8 +95,7 @@ break; dio_config_board(scode); - hplance_init(dev, scode); - if (!register_netdev(dev)) { + if (!hplance_init(dev, scode)) { struct hplance_private *lp = netdev_priv(dev); lp->next_module = root_hplance_dev; root_hplance_dev = lp; @@ -109,7 +108,7 @@ } /* Initialise a single lance board at the given select code */ -static void __init hplance_init(struct net_device *dev, int scode) +static int __init hplance_init(struct net_device *dev, int scode) { const char *name = dio_scodetoname(scode); void *va = dio_scodetoviraddr(scode); @@ -158,6 +157,8 @@ lp->scode = scode; lp->base = va; printk(", irq %d\n", lp->lance.irq); + + return register_netdev(dev); } /* This is disgusting. We have to check the DIO status register for ack every diff -Nru a/drivers/net/ibmlana.c b/drivers/net/ibmlana.c --- a/drivers/net/ibmlana.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/ibmlana.c 2004-06-06 18:38:44 +10:00 @@ -913,6 +913,7 @@ { int force_detect = 0; int slot, z; + int err; int base = 0, irq = 0, iobase = 0, memlen = 0; ibmlana_priv *priv; ibmlana_medium medium; @@ -1014,7 +1015,14 @@ startslot = slot + 1; - return 0; + err = register_netdev(dev); + if (err) { + release_region(iobase, IBM_LANA_IORANGE); + mca_mark_as_unused(slot); + mca_set_adapter_name(slot, ""); + mca_set_adapter_procfn(slot, NULL, NULL); + } + return err; } /* ------------------------------------------------------------------------ @@ -1047,15 +1055,6 @@ dev->irq = irq; dev->base_addr = io; if (ibmlana_probe(dev)) { - free_netdev(dev); - break; - } - if (register_netdev(dev)) { - ibmlana_priv *priv = dev->priv; - release_region(dev->base_addr, IBM_LANA_IORANGE); - mca_mark_as_unused(priv->slot); - mca_set_adapter_name(priv->slot, ""); - mca_set_adapter_procfn(priv->slot, NULL, NULL); free_netdev(dev); break; } diff -Nru a/drivers/net/jazzsonic.c b/drivers/net/jazzsonic.c --- a/drivers/net/jazzsonic.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/jazzsonic.c 2004-06-06 18:38:44 +10:00 @@ -127,17 +127,7 @@ } if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - lp = dev->priv; - vdma_free(lp->rba_laddr); - kfree(lp->rba); - vdma_free(lp->cda_laddr); - kfree(lp); - release_region(dev->base_addr, 0x100); out: free_netdev(dev); return ERR_PTR(err); @@ -283,7 +273,12 @@ SONIC_WRITE(SONIC_FAET,0xffff); SONIC_WRITE(SONIC_MPT,0xffff); + err = register_netdev(dev); + if (err) + goto out4; return 0; +out4: + vdma_free(lp->rba_laddr); out3: kfree(lp->rba); out2: diff -Nru a/drivers/net/lasi_82596.c b/drivers/net/lasi_82596.c --- a/drivers/net/lasi_82596.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/lasi_82596.c 2004-06-06 18:38:44 +10:00 @@ -1150,6 +1150,7 @@ struct device *gen_dev) { int i; + int retval; struct i596_private *lp; char eth_addr[6]; dma_addr_t dma_addr; @@ -1235,7 +1236,13 @@ CHECK_WBACK_INV(dev->mem_start, sizeof(struct i596_private)); - return 0; + retval = register_netdev(netdevice); + if (retval) { + printk(KERN_WARNING __FILE__ ": register_netdevice ret'd %d\n", retval); + dma_free_noncoherent(gen_dev, sizeof(struct i596_private), + (void *)dev->mem_start, dma_addr); + }; + return retval; } @@ -1539,15 +1546,6 @@ return -ENODEV; } - retval = register_netdev(netdevice); - if (retval) { - struct i596_private *lp = netdevice->priv; - printk(KERN_WARNING __FILE__ ": register_netdevice ret'd %d\n", retval); - dma_free_noncoherent(lp->dev, sizeof(struct i596_private), - (void *)netdevice->mem_start, lp->dma_addr); - free_netdev(netdevice); - return -ENODEV; - }; if (dev->id.sversion == 0x72) { ((struct i596_private *)netdevice->priv)->options = OPT_SWAP_PORT; } diff -Nru a/drivers/net/lp486e.c b/drivers/net/lp486e.c --- a/drivers/net/lp486e.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/lp486e.c 2004-06-06 18:38:44 +10:00 @@ -1035,6 +1035,10 @@ i596_port_do(dev, PORT_SELFTEST, "selftest"); i596_port_do(dev, PORT_DUMP, "dump"); #endif + + ret = register_netdev(dev); + if (ret) + goto err_out_kfree; return 0; err_out_kfree: @@ -1325,12 +1329,6 @@ dev->base_addr = io; err = lp486e_probe(dev); if (err) { - free_netdev(dev); - return err; - } - err = register_netdev(dev); - if (err) { - release_region(dev->base_addr, LP486E_TOTAL_SIZE); free_netdev(dev); return err; } diff -Nru a/drivers/net/mac8390.c b/drivers/net/mac8390.c --- a/drivers/net/mac8390.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/mac8390.c 2004-06-06 18:38:44 +10:00 @@ -368,9 +368,6 @@ if (!ndev) goto out; - err = register_netdev(dev); - if (err) - goto out; return dev; out: @@ -438,6 +435,7 @@ }; int access_bitmode; + int err; /* Now fill in our stuff */ dev->open = &mac8390_open; @@ -516,6 +514,10 @@ } NS8390_init(dev, 0); + + err = register_netdev(dev); + if (err) + return err; /* Good, done, now spit out some messages */ printk(KERN_INFO "%s: %s in slot %X (type %s)\n", diff -Nru a/drivers/net/macsonic.c b/drivers/net/macsonic.c --- a/drivers/net/macsonic.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/macsonic.c 2004-06-06 18:38:44 +10:00 @@ -132,12 +132,7 @@ if (err) goto out; found: - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - kfree(dev->priv); out: free_netdev(dev); return ERR_PTR(err); @@ -163,6 +158,7 @@ { struct sonic_local* lp = NULL; int i; + int err; /* Allocate the entire chunk of memory for the descriptors. Note that this cannot cross a 64K boundary. */ @@ -253,7 +249,10 @@ sonic_write(dev, SONIC_FAET, 0xffff); sonic_write(dev, SONIC_MPT, 0xffff); - return 0; + err = register_netdev(dev); + if (err) + kfree(lp); + return err; } int __init mac_onboard_sonic_ethernet_addr(struct net_device* dev) diff -Nru a/drivers/net/ni5010.c b/drivers/net/ni5010.c --- a/drivers/net/ni5010.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/ni5010.c 2004-06-06 18:38:44 +10:00 @@ -161,12 +161,7 @@ } if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - release_region(dev->base_addr, NI5010_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -352,6 +347,10 @@ outb(0, EDLC_XMASK); /* Mask all xmit interrupts */ outb(0xff, EDLC_RCLR); /* Kill all pending rcv interrupts */ outb(0xff, EDLC_XCLR); /* Kill all pending xmt interrupts */ + + err = register_netdev(dev); + if (err) + goto out; printk(KERN_INFO "%s: NI5010 found at 0x%x, using IRQ %d", dev->name, ioaddr, dev->irq); if (dev->dma) printk(" & DMA %d", dev->dma); diff -Nru a/drivers/net/ni52.c b/drivers/net/ni52.c --- a/drivers/net/ni52.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/ni52.c 2004-06-06 18:38:44 +10:00 @@ -406,12 +406,7 @@ if (err) goto out; got_it: - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - release_region(dev->base_addr, NI52_TOTAL_SIZE); out: free_netdev(dev); return ERR_PTR(err); @@ -545,6 +540,9 @@ dev->if_port = 0; + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, NI52_TOTAL_SIZE); diff -Nru a/drivers/net/ni65.c b/drivers/net/ni65.c --- a/drivers/net/ni65.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/ni65.c 2004-06-06 18:38:44 +10:00 @@ -392,12 +392,7 @@ 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); @@ -409,6 +404,7 @@ static int __init ni65_probe1(struct net_device *dev,int ioaddr) { int i,j; + int err; struct priv *p; unsigned long flags; @@ -559,7 +555,11 @@ dev->watchdog_timeo = HZ/2; dev->get_stats = ni65_get_stats; dev->set_multicast_list = set_multicast_list; - return 0; /* everything is OK */ + + err = register_netdev(dev); + if (err) + cleanup_card(dev); + return err; } /* diff -Nru a/drivers/net/seeq8005.c b/drivers/net/seeq8005.c --- a/drivers/net/seeq8005.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/seeq8005.c 2004-06-06 18:38:44 +10:00 @@ -133,12 +133,7 @@ } if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - release_region(dev->base_addr, SEEQ8005_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -341,6 +336,9 @@ dev->set_multicast_list = set_multicast_list; dev->flags &= ~IFF_MULTICAST; + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, SEEQ8005_IO_EXTENT); diff -Nru a/drivers/net/sk_g16.c b/drivers/net/sk_g16.c --- a/drivers/net/sk_g16.c 2004-06-06 18:38:45 +10:00 +++ b/drivers/net/sk_g16.c 2004-06-06 18:38:45 +10:00 @@ -581,16 +581,10 @@ release_region(io, ETHERCARD_TOTAL_SIZE); } } -err_out: free_netdev(dev); return ERR_PTR(err); got_it: - err = register_netdev(dev); - if (err) { - release_region(dev->base_addr, ETHERCARD_TOTAL_SIZE); - goto err_out; - } return dev; } /* End of SK_init */ @@ -833,7 +827,9 @@ SK_print_pos(dev, "End of SK_probe"); SK_print_ram(dev); #endif - return 0; /* Initialization done */ + + return register_netdev(dev); + /* Initialization done */ } /* End of SK_probe() */ diff -Nru a/drivers/net/smc-ultra32.c b/drivers/net/smc-ultra32.c --- a/drivers/net/smc-ultra32.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/smc-ultra32.c 2004-06-06 18:38:44 +10:00 @@ -143,12 +143,7 @@ } if (base >= 0x9000) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -275,6 +270,9 @@ #endif NS8390_init(dev, 0); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, ULTRA32_IO_EXTENT); diff -Nru a/drivers/net/smc9194.c b/drivers/net/smc9194.c --- a/drivers/net/smc9194.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/smc9194.c 2004-06-06 18:38:44 +10:00 @@ -722,13 +722,7 @@ } 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, SMC_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -1018,8 +1012,13 @@ dev->get_stats = smc_query_statistics; dev->set_multicast_list = smc_set_multicast_list; + retval = register_netdev(dev); + if (retval) + goto err_irq; return 0; +err_irq: + free_irq(dev->irq, dev); err_out: release_region(ioaddr, SMC_IO_EXTENT); return retval; diff -Nru a/drivers/net/sun3_82586.c b/drivers/net/sun3_82586.c --- a/drivers/net/sun3_82586.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/sun3_82586.c 2004-06-06 18:38:44 +10:00 @@ -320,13 +320,8 @@ err = sun3_82586_probe1(dev, ioaddr); if (err) goto out1; - err = register_netdev(dev); - if (err) - goto out2; return dev; -out2: - release_region(ioaddr, SUN3_82586_TOTAL_SIZE); out1: free_netdev(dev); out: @@ -389,6 +384,10 @@ dev->set_multicast_list = set_multicast_list; dev->if_port = 0; + + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, SUN3_82586_TOTAL_SIZE); diff -Nru a/drivers/net/sun3lance.c b/drivers/net/sun3lance.c --- a/drivers/net/sun3lance.c 2004-06-06 18:38:44 +10:00 +++ b/drivers/net/sun3lance.c 2004-06-06 18:38:44 +10:00 @@ -279,16 +279,9 @@ if (!lance_probe(dev)) goto out; - err = register_netdev(dev); - if (err) - goto out1; found = 1; return dev; -out1: -#ifdef CONFIG_SUN3 - iounmap((void *)dev->base_addr); -#endif out: free_netdev(dev); return ERR_PTR(err); @@ -342,6 +335,7 @@ REGA(CSR0) = CSR0_STOP; + /* XXX - leak */ request_irq(LANCE_IRQ, lance_interrupt, SA_INTERRUPT, "SUN3 Lance", dev); dev->irq = (unsigned short)LANCE_IRQ; @@ -397,7 +391,15 @@ memset( &lp->stats, 0, sizeof(lp->stats) ); + if (register_netdev(dev)) + goto out_unmap; return 1; + +out_unmap: +#ifdef CONFIG_SUN3 + iounmap((void *)dev->base_addr); +#endif + return 0; } static int lance_open( struct net_device *dev ) --a8Wt8u1KmwUX3Y2C-- From manfred@colorfullife.com Sun Jun 6 06:30:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 06:31:01 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56DUtgi030352 for ; Sun, 6 Jun 2004 06:30:57 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i56DURLw011269; Sun, 6 Jun 2004 15:30:29 +0200 Message-ID: <40C31C71.6000101@colorfullife.com> Date: Sun, 06 Jun 2004 15:30:25 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary N Spiess CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address References: <200406041451590078.0BC23855@136.179.85.112> In-Reply-To: <200406041451590078.0BC23855@136.179.85.112> Content-Type: multipart/mixed; boundary="------------040509070707030205040103" X-archive-position: 5658 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: 3926 Lines: 121 This is a multi-part message in MIME format. --------------040509070707030205040103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gary N Spiess wrote: >Jeff, >This is the first of a series of patches needed to support our product using the DP83815. >This patch accepts the MAC address as a parameter because our implementation does not have an EEPROM. I tried to upgrade to the new module_param_array() macro, but couldn't find a tutorial on the new param scheme. > Ok. Appending "natsemi.ethaddr=00:01:02:04:05:06" works. > To get things working for our development, I use a __setup() wrapper to get "ethaddr=" from the linux command line. > > That's not a reason to merge a hack >+ if (find_cnt < ethaddr_num) > > I think we should add a special case: if strlen(ethaddr[find_cnt]) is 0, then the address from the eeprom is used - this allows to replace one mac address if multiple nics are installed. >+ { > > Coding style: the { should be in the same line as the if >+ int i, a[6]; > > i already exists, no need to define another instance. I've appended an updated patch - could you test it? But: I'm not sure that the change is required. What about just setting the mac to 0, and the actual mac address is set from user space? It's possible to set the mac address with # ifconfig eth2 ether 80:01:02:03:04:05 Is there a reason why you cannot set the mac address from user space? -- Manfred --------------040509070707030205040103 Content-Type: text/plain; name="natsemi-2.6.6-1.patch-new" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="natsemi-2.6.6-1.patch-new" --- 2.6/drivers/net/natsemi.c 2004-05-10 04:31:59.000000000 +0200 +++ build-2.6/drivers/net/natsemi.c 2004-06-06 15:27:12.124436291 +0200 @@ -147,6 +147,7 @@ #include #include +#include #include #include #include @@ -209,6 +210,8 @@ #define MAX_UNITS 8 /* More are supported, limit only on options */ static int options[MAX_UNITS]; static int full_duplex[MAX_UNITS]; +static char *ethaddr[MAX_UNITS] = {NULL, }; +static int ethaddr_num = 0; /* Operational parameters that are set at compile time. */ @@ -256,6 +259,7 @@ 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_param_array(ethaddr, charp, ethaddr_num, S_IRUGO); MODULE_PARM_DESC(max_interrupt_work, "DP8381x maximum events handled per interrupt"); MODULE_PARM_DESC(mtu, "DP8381x MTU (all boards)"); @@ -265,6 +269,7 @@ MODULE_PARM_DESC(options, "DP8381x: Bits 0-3: media type, bit 17: full duplex"); MODULE_PARM_DESC(full_duplex, "DP8381x full duplex setting(s) (1)"); +MODULE_PARM_DESC(ethaddr, "DP8381x MAC addr(s) xx:xx:xx:xx:xx:xx"); /* Theory of Operation @@ -776,13 +781,21 @@ goto err_ioremap; } - /* Work around the dropped serial bit. */ - prev_eedata = eeprom_read(ioaddr, 6); - for (i = 0; i < 3; i++) { - int eedata = eeprom_read(ioaddr, i + 7); - dev->dev_addr[i*2] = (eedata << 1) + (prev_eedata >> 15); - dev->dev_addr[i*2+1] = eedata >> 7; - prev_eedata = eedata; + if (find_cnt < ethaddr_num && strlen(ethaddr[find_cnt]) > 0) { + int a[6]; + sscanf(ethaddr[find_cnt], "%2x:%2x:%2x:%2x:%2x:%2x", + &a[0], &a[1], &a[2], &a[3], &a[4], &a[5]); + for (i = 6; i--; ) + dev->dev_addr[i] = (unsigned char)a[i]; + } else { + /* Work around the dropped serial bit. */ + prev_eedata = eeprom_read(ioaddr, 6); + for (i = 0; i < 3; i++) { + int eedata = eeprom_read(ioaddr, i + 7); + dev->dev_addr[i*2] = (eedata << 1) + (prev_eedata >> 15); + dev->dev_addr[i*2+1] = eedata >> 7; + prev_eedata = eedata; + } } dev->base_addr = ioaddr; --------------040509070707030205040103-- From manfred@colorfullife.com Sun Jun 6 08:50:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 08:50:26 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56FoLgi003507 for ; Sun, 6 Jun 2004 08:50:23 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i56FoGLw012092; Sun, 6 Jun 2004 17:50:17 +0200 Message-ID: <40C33D38.1060102@colorfullife.com> Date: Sun, 06 Jun 2004 17:50:16 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary N Spiess CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 3/4 External PHY operation References: <200406041455290031.0BC56C76@136.179.85.112> In-Reply-To: <200406041455290031.0BC56C76@136.179.85.112> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5659 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: 1487 Lines: 40 Gary N Spiess wrote: >Relocate the internal phy to phy_address=1, and add find_mii() to locate the address of the external mii phy. > What if phy_address 1 is already in use? > } > + if (phy_id == PHY_ADDR_INTERNAL) > + phy_id = np->phy_addr_external; > + Hmm. If the phy_id is internal then it's external. What do you actually try to do? If I understand the hardware correctly, it supports - an internal PHY. Accessed through mapped registers. Used if dev->if_port == PORT_TP. - an external MII bus. Accessed by bit banging. Used if dev->if_port == PORT_MII. - most users of mdio_{read,write} want to access the currently selected PHY, but they call mdio_read(,1,). The "if (phy_id ==INTERNAL) phy_id=external" line is a hack to handle that. What about defining a PHY_ADDR_CUR (32, whatever). Everyone except the probe code uses that value and mdio_read selects the correct port/phy value from the dev structure. Or create a mdio_read_cur() function. > + /* if external phy, then DSPCFG register isn't functional. > + Fix the value here so the "nasty random phy-reset" code doesn't > + think it needs to reinitialize the chip. > + */ > + if (dev->if_port != PORT_TP) > + np->dspcfg = 0; > + What about making the phy reset itself dependant on if->if_port? This approach just asks for bugs - switch with ethtool from PORT_TP to PORT_MII and suddenly short cables stop working. -- Manfred From manfred@colorfullife.com Sun Jun 6 09:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 09:01:19 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56G1Egi004027 for ; Sun, 6 Jun 2004 09:01:15 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i56G19Lw012158; Sun, 6 Jun 2004 18:01:10 +0200 Message-ID: <40C33FC5.2070604@colorfullife.com> Date: Sun, 06 Jun 2004 18:01:09 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary N Spiess CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 4/4 External Fibre phy References: <200406041456330453.0BC6681C@136.179.85.112> In-Reply-To: <200406041456330453.0BC6681C@136.179.85.112> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5660 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: 659 Lines: 23 Gary N Spiess wrote: > > +/* add a couple of MII definitions specific to a PORT_FIBRE > implementation */ > +#define MII_MCTRL 0x15 /* mode control register */ > +#define MII_IN_FX_MODE 0x0001 /* full duplex */ > +#define MII_DIS_SCRM 0x0004 /* disable scrambler */ > Specific to a PORT_FIBRE implementation or specific to the PHY you are using? I think register 0x15 is implementation specific. Why do you actually want to handle the fibre phy as a new port? I'd handle phy specific code by reading the MII_PHYSID{1,2} register and then adding a special case if your phy is detected. The port can remain at PORT_MII. -- Manfred From margitsw@t-online.de Sun Jun 6 14:52:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 14:52:16 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56Lpvgi013480 for ; Sun, 6 Jun 2004 14:52:07 -0700 Received: from fwd10.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1BWZk9-0002ii-03; Sat, 05 Jun 2004 13:53:45 +0200 Received: from roglap.local (Xds51cZbweSHfqFpZEEPBRMT3fJCdbe1JtO7vUdIfea8QHCDAhAnrj@[217.224.17.118]) by fwd10.sul.t-online.com with esmtp id 1BWZk0-1rUXY00; Sat, 5 Jun 2004 13:53:36 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 12/17 linux-2.6.7-rc2] prism54: Add likely/unlikely (resend again) Date: Sat, 5 Jun 2004 15:51:07 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Cc: netdev@oss.sgi.com Content-Type: Multipart/Mixed; boundary="Boundary-00=_L/cwA561oBMa7vW" Message-Id: <200406051551.07667.margitsw@t-online.de> X-Seen: false X-ID: Xds51cZbweSHfqFpZEEPBRMT3fJCdbe1JtO7vUdIfea8QHCDAhAnrj X-archive-position: 5662 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: 3531 Lines: 97 --Boundary-00=_L/cwA561oBMa7vW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Previous patch 12 doesn't compile, sorry. Other patches unaffected. * islpci_eth.c : Do some likely/unlikely --Boundary-00=_L/cwA561oBMa7vW Content-Type: text/x-diff; charset="us-ascii"; name="12-add-likely.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="12-add-likely.patch" diff -NaurEbB linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.6ct/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 14:41:32.820447976 +0200 +++ linux-2.6.6-01/drivers/net/wireless/prism54/islpci_eth.c 2004-05-28 15:33:42.187711840 +0200 @@ -105,7 +105,7 @@ /* check whether the destination queue has enough fragments for the frame */ curr_frag = le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ]); - if (curr_frag - priv->free_data_tx >= ISL38XX_CB_TX_QSIZE) { + if (unlikely(curr_frag - priv->free_data_tx >= ISL38XX_CB_TX_QSIZE)) { printk(KERN_ERR "%s: transmit device queue full when awake\n", ndev->name); netif_stop_queue(ndev); @@ -121,7 +121,7 @@ /* Check alignment and WDS frame formatting. The start of the packet should * be aligned on a 4-byte boundary. If WDS is enabled add another 6 bytes * and add WDS address information */ - if (((long) skb->data & 0x03) | init_wds) { + if (unlikely(((long) skb->data & 0x03) | init_wds)) { /* get the number of bytes to add and re-allign */ offset = (4 - (long) skb->data) & 0x03; offset += init_wds ? 6 : 0; @@ -192,7 +192,7 @@ pci_map_address = pci_map_single(priv->pdev, (void *) skb->data, skb->len, PCI_DMA_TODEVICE); - if (pci_map_address == 0) { + if (unlikely(pci_map_address == 0)) { printk(KERN_WARNING "%s: cannot map buffer to PCI\n", ndev->name); @@ -382,10 +382,10 @@ skb->dev = ndev; /* take care of monitor mode and spy monitoring. */ - if (priv->iw_mode == IW_MODE_MONITOR) + if (unlikely(priv->iw_mode == IW_MODE_MONITOR)) discard = islpci_monitor_rx(priv, &skb); else { - if (skb->data[2 * ETH_ALEN] == 0) { + if (unlikely(skb->data[2 * ETH_ALEN] == 0)) { /* The packet has a rx_annex. Read it for spy monitoring, Then * remove it, while keeping the 2 leading MAC addr. */ @@ -418,7 +418,7 @@ skb->data[0], skb->data[1], skb->data[2], skb->data[3], skb->data[4], skb->data[5]); #endif - if (discard) { + if (unlikely(discard)) { dev_kfree_skb(skb); skb = NULL; } else @@ -434,7 +434,8 @@ index - priv->free_data_rx < ISL38XX_CB_RX_QSIZE) { /* allocate an sk_buff for received data frames storage * include any required allignment operations */ - if (skb = dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2), skb == NULL) { + skb = dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2); + if (unlikely(skb == NULL)) { /* error allocating an sk_buff structure elements */ DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n"); break; @@ -454,7 +455,7 @@ pci_map_single(priv->pdev, (void *) skb->data, MAX_FRAGMENT_SIZE_RX + 2, PCI_DMA_FROMDEVICE); - if (priv->pci_map_rx_address[index] == (dma_addr_t) NULL) { + if (unlikely(priv->pci_map_rx_address[index] == (dma_addr_t) NULL)) { /* error mapping the buffer to device accessable memory address */ DEBUG(SHOW_ERROR_MESSAGES, "Error mapping DMA address\n"); --Boundary-00=_L/cwA561oBMa7vW-- From rl@hellgate.ch Sun Jun 6 15:00:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 15:01:10 -0700 (PDT) Received: from mail3.bluewin.ch (mail3.bluewin.ch [195.186.1.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56LxLgi013775 for ; Sun, 6 Jun 2004 15:00:56 -0700 Received: from k3.hellgate.ch (83.76.121.213) by mail3.bluewin.ch (Bluewin AG 7.0.028) id 40A46963002E1441; Sun, 6 Jun 2004 16:53:36 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 287878B29E8; Sun, 6 Jun 2004 18:53:36 +0200 (CEST) Date: Sun, 6 Jun 2004 18:53:36 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [2/3][PATCH 2.6] netdrivers: fix mc_filter on big-endian arch Message-ID: <20040606165336.GA13840@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1664 Lines: 40 This untested patch fixes hardware mc filters for tulip_core, winbond, and atp. Hopefully :-). Please review and test. Signed-off-by: Roger Luethi --- 2.6-bk/drivers/net/tulip/winbond-840.c.orig 2004-06-06 18:03:51.502473098 +0200 +++ 2.6-bk/drivers/net/tulip/winbond-840.c 2004-06-06 18:04:18.807205433 +0200 @@ -1439,7 +1439,7 @@ i++, mclist = mclist->next) { int filterbit = (ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26) ^ 0x3F; filterbit &= 0x3f; - mc_filter[filterbit >> 5] |= cpu_to_le32(1 << (filterbit & 31)); + mc_filter[filterbit >> 5] |= 1 << (filterbit & 31); } rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys; } --- 2.6-bk/drivers/net/tulip/tulip_core.c.orig 2004-06-06 18:03:46.319283616 +0200 +++ 2.6-bk/drivers/net/tulip/tulip_core.c 2004-06-06 18:04:36.263478849 +0200 @@ -1059,7 +1059,7 @@ else filterbit = ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26; filterbit &= 0x3f; - mc_filter[filterbit >> 5] |= cpu_to_le32(1 << (filterbit & 31)); + mc_filter[filterbit >> 5] |= 1 << (filterbit & 31); if (tulip_debug > 2) { printk(KERN_INFO "%s: Added filter for %2.2x:%2.2x:%2.2x:" "%2.2x:%2.2x:%2.2x %8.8x bit %d.\n", dev->name, --- 2.6-bk/drivers/net/atp.c.orig 2004-06-06 18:03:34.351155626 +0200 +++ 2.6-bk/drivers/net/atp.c 2004-06-06 18:04:55.176526236 +0200 @@ -909,7 +909,7 @@ i++, mclist = mclist->next) { int filterbit = ether_crc_le(ETH_ALEN, mclist->dmi_addr) & 0x3f; - mc_filter[filterbit >> 5] |= cpu_to_le32(1 << (filterbit & 31)); + mc_filter[filterbit >> 5] |= 1 << (filterbit & 31); } new_mode = CMR2h_Normal; } From ifilipau@giga-stream.de Sun Jun 6 15:10:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 15:10:43 -0700 (PDT) Received: from natnoddy.rzone.de (natnoddy.rzone.de [81.169.145.166]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56M9ngi014280 for ; Sun, 6 Jun 2004 15:09:52 -0700 Received: from giga-stream.de ([212.18.200.6]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i528MxD9010823; Wed, 2 Jun 2004 10:22:59 +0200 (MEST) Message-ID: <40BD8E49.3070605@giga-stream.de> Date: Wed, 02 Jun 2004 10:22:33 +0200 From: "Ihar 'Philips' Filipau" Organization: Giga Stream User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: Linux Kernel Mailing List Subject: e1000 question Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030902050009050703060905" X-archive-position: 5664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ifilipau@giga-stream.de Precedence: bulk X-list: netdev Content-Length: 6355 Lines: 107 This is a cryptographically signed message in MIME format. --------------ms030902050009050703060905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [ If this is wrong ML, will appreciate pointer to correct one. ] [ CC: me, please - I'm not sub'd. ] [ Intel's driver as in 2.6.5 - http://lxr.linux.no/source/drivers/net/e1000/e1000_main.c?v=2.6.5 ] I'm looking into e1000 driver in irq handling and what I see, puzzles me. Functions e1000_clean_{t,r}x_irq are very similar: both of them are checking descriptor flag updated by nic. Host CPU, obviously, to perform this check, will cache descriptor. If, say e1000_clean_rx_irq() will be called twice in short time range, I expect that it can miss change of the flag, since old flag may still sit in host CPU cache. Am I missing something here? -- Johnson's law: Systems resemble the organizations that create them. -- ___ ___ Ihar 'Philips' Filipau \ / Sr. Software Developer Tel: +49 681 959 16 0 \ / GIGA STREAM Fax: +49 681 959 16 100 \/ Konrad Zuse Strasse 7 Mobile: +49 173 39 462 49 /\ 66115 Saarbruecken email: ifilipau@giga-stream.de / \ Germany www: http://www.giga-stream.de ___/ \___ Switching for success --------------ms030902050009050703060905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXDCC AwwwggJ1oAMCAQICAwp5RzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwNDEyMDI1OVoXDTA0MDgwMzEyMDI1OVowSTEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEmMCQGCSqGSIb3DQEJARYXaWZpbGlw YXVAZ2lnYS1zdHJlYW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCh23lX NmvjlqAwzhanhztIary04F8dGaAt4ABMEMiNf+XD353lzpIHcHVzTH0OY4c9LtFNbt5V+XZT JoENrCLlDDCerzYgVNEejB173dpMQW1mAoYgl5AJZArvjgojcSKWG+BMaD2ozo3NVAPMAkwD Zhk25/WtbqN4UDf2mGljaU4/SETZKUJ+pNeeiXoz2KHlkJyZ8zubjJuR7xf5hPMpfsV+ePHI ohDZAFlM58D6wpgbDp8DO5CL4dnqSLeW+xCv+ETDIATu8B80Cv4QifhTWIJsosEzFP6CljUE hdBDbr3sgPTdVbTewTptD4hKodp67/2WjWsS6DMZwZl7oyTTAgMBAAGjNDAyMCIGA1UdEQQb MBmBF2lmaWxpcGF1QGdpZ2Etc3RyZWFtLmRlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE BQADgYEAXUjvmMsvEKRjvE8E2xjjymWYARwQ9fj/jbf/bpEy+fxub4It78X93RyBEazIciky +H3ZVmjTUH+dnxzYpBrEztVIuKDsCkuF5++j+NXDsELsuOFNX+1Z/YZ4ol5rJaensb/ZwflA byaeNV7+nl7qUgPxTanF16QDv13+EumlMdUwggMMMIICdaADAgECAgMKeUcwDQYJKoZIhvcN AQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA4 MDQxMjAyNTlaFw0wNDA4MDMxMjAyNTlaMEkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxJjAkBgkqhkiG9w0BCQEWF2lmaWxpcGF1QGdpZ2Etc3RyZWFtLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAodt5VzZr45agMM4Wp4c7SGq8tOBfHRmgLeAATBDI jX/lw9+d5c6SB3B1c0x9DmOHPS7RTW7eVfl2UyaBDawi5Qwwnq82IFTRHowde93aTEFtZgKG IJeQCWQK744KI3EilhvgTGg9qM6NzVQDzAJMA2YZNuf1rW6jeFA39phpY2lOP0hE2SlCfqTX nol6M9ih5ZCcmfM7m4ybke8X+YTzKX7FfnjxyKIQ2QBZTOfA+sKYGw6fAzuQi+HZ6ki3lvsQ r/hEwyAE7vAfNAr+EIn4U1iCbKLBMxT+gpY1BIXQQ2697ID03VW03sE6bQ+ISqHaeu/9lo1r EugzGcGZe6Mk0wIDAQABozQwMjAiBgNVHREEGzAZgRdpZmlsaXBhdUBnaWdhLXN0cmVhbS5k ZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF1I75jLLxCkY7xPBNsY48plmAEc EPX4/423/26RMvn8bm+CLe/F/d0cgRGsyHIpMvh92VZo01B/nZ8c2KQaxM7VSLig7ApLhefv o/jVw7BC7LjhTV/tWf2GeKJeayWnp7G/2cH5QG8mnjVe/p5e6lID8U2pxdekA79d/hLppTHV MIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAw MDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXa iBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1 Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3 MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGx S0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcN rUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTq JmmHf0iezqWf54TYyWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJl ZW1haWwgUlNBIDIwMDAuOC4zMAIDCnlHMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDYwMjA4MjIzM1owIwYJKoZIhvcNAQkE MRYEFMQjlukuEZWwcfEMLki2IKOVFvgNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnlHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3 dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBG cmVlbWFpbCBSU0EgMjAwMC44LjMwAgMKeUcwDQYJKoZIhvcNAQEBBQAEggEAbJOiYkqZG2Li 3Djf5BQwImu3I3I10yDeL1g5fGfL7BA1Lw4tU5FCZGNLBOtv481+mGloTCcCDqW7VeZgKust GARg4T6VglRP0hG2gxHAW6oiCi0oLtkQAc3cCqj8LdeZgd/NGFQsJ7aF3X1Lxb8fShe7mCZM mm/uHrVf+sTV76GkwbGOyrHe3rG842Y/4fjgR3stiuQOr0YVOor0DixlU8iyCIbAFcUi1Wf3 +DEfB7X/bXhVTy2Z98WDCVd/Be1cTsBMCRq5wUt7b+xk9CvQE7iWTX8jcnd61IaE949F2Unn K3GRPqvfnM46smsguRq5nsSz8CVsJQHC29CQQ/4I4gAAAAAAAA== --------------ms030902050009050703060905-- From mitch@sfgoth.com Sun Jun 6 15:16:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 15:16:28 -0700 (PDT) Received: from gaz.sfgoth.com (gaz.sfgoth.com [69.36.241.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56MGNgi014666 for ; Sun, 6 Jun 2004 15:16:24 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.10/8.12.9) with ESMTP id i56MJhIp007796 for ; Sun, 6 Jun 2004 15:19:43 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.10/8.12.6/Submit) id i56MJhKe007795 for netdev@oss.sgi.com; Sun, 6 Jun 2004 15:19:43 -0700 (PDT) (envelope-from mitch) Date: Sun, 6 Jun 2004 15:19:43 -0700 From: Mitchell Blank Jr To: netdev@oss.sgi.com Subject: Re: e1000 question Message-ID: <20040606221943.GA6197@gaz.sfgoth.com> References: <40BD8E49.3070605@giga-stream.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BD8E49.3070605@giga-stream.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 5665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Content-Length: 337 Lines: 10 Ihar 'Philips' Filipau wrote: > I'm looking into e1000 driver in irq handling and what I see, > puzzles me. [...] Wow - thats some lag. I already answered this question when I it got posted to lkml four days ago. Looking at the headers it looks like there was a 4 day delay in the same email making it to the netdev list! -Mitch From scott.feldman@intel.com Sun Jun 6 15:34:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 15:34:56 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56MYpgi015563 for ; Sun, 6 Jun 2004 15:34: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 i550b8Qe021731; Sat, 5 Jun 2004 00:37:08 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i550cDDV005604; Sat, 5 Jun 2004 00:38:33 GMT Received: from sfeldma-ich5.jf.intel.com ([134.134.3.54]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060417374109572 ; Fri, 04 Jun 2004 17:37:41 -0700 Date: Fri, 4 Jun 2004 17:35:26 -0700 (PDT) From: Scott Feldman To: jgarzik@pobox.com cc: netdev@oss.sgi.com, scott.feldman@intel.com Subject: [PATCH 2.6] e100: use NAPI mode all the time Message-ID: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 5666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 4404 Lines: 123 I see no reason to keep the non-NAPI option for e100. This patch removes the CONFIG_E100_NAPI option and puts the driver in NAPI mode all the time. Matches the way tg3 works. Unless someone has a really good reason to keep the non-NAPI mode, this should go in for 2.6.7. -scott ---------------- diff -Naurp linux-2.6.7-rc2-bk5/drivers/net/e100.c linux-2.6.7-rc2-bk5.mod/drivers/net/e100.c --- linux-2.6.7-rc2-bk5/drivers/net/e100.c 2004-06-04 15:58:07.000000000 -0700 +++ linux-2.6.7-rc2-bk5.mod/drivers/net/e100.c 2004-06-04 16:02:04.000000000 -0700 @@ -87,9 +87,8 @@ * cb_to_use is the next CB to use for queuing a command; cb_to_clean * is the next CB to check for completion; cb_to_send is the first * CB to start on in case of a previous failure to resume. CB clean - * up happens in interrupt context in response to a CU interrupt, or - * in dev->poll in the case where NAPI is enabled. cbs_avail keeps - * track of number of free CB resources available. + * up happens in interrupt context in response to a CU interrupt. + * cbs_avail keeps track of number of free CB resources available. * * Hardware padding of short packets to minimum packet size is * enabled. 82557 pads with 7Eh, while the later controllers pad @@ -112,9 +111,8 @@ * replacement RFDs cannot be allocated, or the RU goes non-active, * the RU must be restarted. Frame arrival generates an interrupt, * and Rx indication and re-allocation happen in the same context, - * therefore no locking is required. If NAPI is enabled, this work - * happens in dev->poll. A software-generated interrupt is gen- - * erated from the watchdog to recover from a failed allocation + * therefore no locking is required. A software-generated interrupt + * is generated from the watchdog to recover from a failed allocation * senario where all Rx resources have been indicated and none re- * placed. * @@ -126,8 +124,6 @@ * supported. Tx Scatter/Gather is not supported. Jumbo Frames is * not supported (hardware limitation). * - * NAPI support is enabled with CONFIG_E100_NAPI. - * * MagicPacket(tm) WoL support is enabled/disabled via ethtool. * * Thanks to JC (jchapman@katalix.com) for helping with @@ -158,7 +154,7 @@ #define DRV_NAME "e100" -#define DRV_VERSION "3.0.18" +#define DRV_VERSION "3.0.22-NAPI" #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" #define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" #define PFX DRV_NAME ": " @@ -1463,11 +1459,7 @@ static inline int e100_rx_indicate(struc nic->net_stats.rx_packets++; nic->net_stats.rx_bytes += actual_size; nic->netdev->last_rx = jiffies; -#ifdef CONFIG_E100_NAPI netif_receive_skb(skb); -#else - netif_rx(skb); -#endif if(work_done) (*work_done)++; } @@ -1562,20 +1554,12 @@ static irqreturn_t e100_intr(int irq, vo if(stat_ack & stat_ack_rnr) nic->ru_running = 0; -#ifdef CONFIG_E100_NAPI e100_disable_irq(nic); netif_rx_schedule(netdev); -#else - if(stat_ack & stat_ack_rx) - e100_rx_clean(nic, NULL, 0); - if(stat_ack & stat_ack_tx) - e100_tx_clean(nic); -#endif return IRQ_HANDLED; } -#ifdef CONFIG_E100_NAPI static int e100_poll(struct net_device *netdev, int *budget) { struct nic *nic = netdev_priv(netdev); @@ -1598,7 +1582,6 @@ static int e100_poll(struct net_device * return 1; } -#endif #ifdef CONFIG_NET_POLL_CONTROLLER static void e100_netpoll(struct net_device *netdev) @@ -2137,10 +2120,8 @@ static int __devinit e100_probe(struct p SET_ETHTOOL_OPS(netdev, &e100_ethtool_ops); netdev->tx_timeout = e100_tx_timeout; netdev->watchdog_timeo = E100_WATCHDOG_PERIOD; -#ifdef CONFIG_E100_NAPI netdev->poll = e100_poll; netdev->weight = E100_NAPI_WEIGHT; -#endif #ifdef CONFIG_NET_POLL_CONTROLLER netdev->poll_controller = e100_netpoll; #endif diff -Naurp linux-2.6.7-rc2-bk5/drivers/net/Kconfig linux-2.6.7-rc2-bk5.mod/drivers/net/Kconfig --- linux-2.6.7-rc2-bk5/drivers/net/Kconfig 2004-06-04 15:58:26.000000000 -0700 +++ linux-2.6.7-rc2-bk5.mod/drivers/net/Kconfig 2004-06-04 16:02:34.000000000 -0700 @@ -1498,10 +1498,6 @@ config E100 . The module will be called e100. -config E100_NAPI - bool "Use Rx Polling (NAPI)" - depends on E100 - config LNE390 tristate "Mylex EISA LNE390A/B support (EXPERIMENTAL)" depends on NET_PCI && EISA && EXPERIMENTAL From tmattox@engr.uky.edu Sun Jun 6 15:57:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 15:57:28 -0700 (PDT) Received: from spitfire.ecc.engr.uky.edu (spitfire.ecc.engr.uky.edu [128.163.144.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56MvMgi016198 for ; Sun, 6 Jun 2004 15:57:22 -0700 Received: from kaos.ee.engr.uky.edu ([128.163.147.210] helo=[192.168.0.186]) by spitfire.ecc.engr.uky.edu with esmtp (Exim 4.34) id 1BX6Zs-000Mct-4r; Sun, 06 Jun 2004 18:57:21 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, jgarzik@pobox.com From: Tim Mattox Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time Date: Sun, 6 Jun 2004 18:57:18 -0400 To: Scott Feldman X-Mailer: Apple Mail (2.618) X-archive-position: 5667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@engr.uky.edu Precedence: bulk X-list: netdev Content-Length: 5657 Lines: 155 Scott, Have you considered how this interacts with multiple e100's bonded together with Linux channel bonding? I've CC'd the bonding developer mailing list to flush out any more opinions on this. I have yet to set up a good test system, but my impression has been that NAPI and channel bonding would lead to lots of packet re-ordering load for the CPU that could outweigh the interrupt load savings. Does anyone have experience with this? Also, depending on the setting of /proc/sys/net/ipv4/tcp_reordering the TCP stack might do aggressive NACKs because of a false-positive on dropped packets due to the large reordering that could occur with NAPI and bonding combined. In short, unless there has been study on this, I would suggest not yet removing support for non-NAPI mode on any network driver. On Jun 4, 2004, at 8:35 PM, Scott Feldman wrote: > I see no reason to keep the non-NAPI option for e100. This patch > removes > the CONFIG_E100_NAPI option and puts the driver in NAPI mode all the > time. > Matches the way tg3 works. > > Unless someone has a really good reason to keep the non-NAPI mode, this > should go in for 2.6.7. > > -scott > > ---------------- > > diff -Naurp linux-2.6.7-rc2-bk5/drivers/net/e100.c > linux-2.6.7-rc2-bk5.mod/drivers/net/e100.c > --- linux-2.6.7-rc2-bk5/drivers/net/e100.c 2004-06-04 > 15:58:07.000000000 -0700 > +++ linux-2.6.7-rc2-bk5.mod/drivers/net/e100.c 2004-06-04 > 16:02:04.000000000 -0700 > @@ -87,9 +87,8 @@ > * cb_to_use is the next CB to use for queuing a command; cb_to_clean > * is the next CB to check for completion; cb_to_send is the first > * CB to start on in case of a previous failure to resume. CB clean > - * up happens in interrupt context in response to a CU interrupt, or > - * in dev->poll in the case where NAPI is enabled. cbs_avail keeps > - * track of number of free CB resources available. > + * up happens in interrupt context in response to a CU interrupt. > + * cbs_avail keeps track of number of free CB resources available. > * > * Hardware padding of short packets to minimum packet size is > * enabled. 82557 pads with 7Eh, while the later controllers pad > @@ -112,9 +111,8 @@ > * replacement RFDs cannot be allocated, or the RU goes non-active, > * the RU must be restarted. Frame arrival generates an interrupt, > * and Rx indication and re-allocation happen in the same context, > - * therefore no locking is required. If NAPI is enabled, this work > - * happens in dev->poll. A software-generated interrupt is gen- > - * erated from the watchdog to recover from a failed allocation > + * therefore no locking is required. A software-generated interrupt > + * is generated from the watchdog to recover from a failed allocation > * senario where all Rx resources have been indicated and none re- > * placed. > * > @@ -126,8 +124,6 @@ > * supported. Tx Scatter/Gather is not supported. Jumbo Frames is > * not supported (hardware limitation). > * > - * NAPI support is enabled with CONFIG_E100_NAPI. > - * > * MagicPacket(tm) WoL support is enabled/disabled via ethtool. > * > * Thanks to JC (jchapman@katalix.com) for helping with > @@ -158,7 +154,7 @@ > > > #define DRV_NAME "e100" > -#define DRV_VERSION "3.0.18" > +#define DRV_VERSION "3.0.22-NAPI" > #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" > #define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" > #define PFX DRV_NAME ": " > @@ -1463,11 +1459,7 @@ static inline int e100_rx_indicate(struc > nic->net_stats.rx_packets++; > nic->net_stats.rx_bytes += actual_size; > nic->netdev->last_rx = jiffies; > -#ifdef CONFIG_E100_NAPI > netif_receive_skb(skb); > -#else > - netif_rx(skb); > -#endif > if(work_done) > (*work_done)++; > } > @@ -1562,20 +1554,12 @@ static irqreturn_t e100_intr(int irq, vo > if(stat_ack & stat_ack_rnr) > nic->ru_running = 0; > > -#ifdef CONFIG_E100_NAPI > e100_disable_irq(nic); > netif_rx_schedule(netdev); > -#else > - if(stat_ack & stat_ack_rx) > - e100_rx_clean(nic, NULL, 0); > - if(stat_ack & stat_ack_tx) > - e100_tx_clean(nic); > -#endif > > return IRQ_HANDLED; > } > > -#ifdef CONFIG_E100_NAPI > static int e100_poll(struct net_device *netdev, int *budget) > { > struct nic *nic = netdev_priv(netdev); > @@ -1598,7 +1582,6 @@ static int e100_poll(struct net_device * > > return 1; > } > -#endif > > #ifdef CONFIG_NET_POLL_CONTROLLER > static void e100_netpoll(struct net_device *netdev) > @@ -2137,10 +2120,8 @@ static int __devinit e100_probe(struct p > SET_ETHTOOL_OPS(netdev, &e100_ethtool_ops); > netdev->tx_timeout = e100_tx_timeout; > netdev->watchdog_timeo = E100_WATCHDOG_PERIOD; > -#ifdef CONFIG_E100_NAPI > netdev->poll = e100_poll; > netdev->weight = E100_NAPI_WEIGHT; > -#endif > #ifdef CONFIG_NET_POLL_CONTROLLER > netdev->poll_controller = e100_netpoll; > #endif > diff -Naurp linux-2.6.7-rc2-bk5/drivers/net/Kconfig > linux-2.6.7-rc2-bk5.mod/drivers/net/Kconfig > --- linux-2.6.7-rc2-bk5/drivers/net/Kconfig 2004-06-04 > 15:58:26.000000000 -0700 > +++ linux-2.6.7-rc2-bk5.mod/drivers/net/Kconfig 2004-06-04 > 16:02:34.000000000 -0700 > @@ -1498,10 +1498,6 @@ config E100 > . The module > will be called e100. > > -config E100_NAPI > - bool "Use Rx Polling (NAPI)" > - depends on E100 > - > config LNE390 > tristate "Mylex EISA LNE390A/B support (EXPERIMENTAL)" > depends on NET_PCI && EISA && EXPERIMENTAL > -- Tim Mattox - tmattox@engr.uky.edu - http://homepage.mac.com/tmattox/ http://aggregate.org/KAOS/ - http://advogato.org/person/tmattox/ From rl@hellgate.ch Sun Jun 6 16:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 16:24:03 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i56NO0gi020031 for ; Sun, 6 Jun 2004 16:24:01 -0700 Received: from k3.hellgate.ch (83.76.121.213) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C000D5D62; Sun, 6 Jun 2004 16:53:23 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id EE2B78B29E8; Sun, 6 Jun 2004 18:53:22 +0200 (CEST) Date: Sun, 6 Jun 2004 18:53:22 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [0/3] mc_filter on big-endian arch Message-ID: <20040606165322.GA13247@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 899 Lines: 19 A.J. from VIA Networking Technologies noticed that via-rhine is using cpu_to_le32() when preparing mc_filter hashes. I confirmed that this breaks Rhine hardware multicast filters on big-endian architectures. A bunch of other drivers are affected, too. I'll post a patch for 2.6 atp, winbond, and tulip_core (typhoon could be okay at first glance). Those are entirely untested due to lack of hardware. If the patches are ack'ed by the respective maintainers, we might want to fix up the tulips in 2.4 as well. atp still uses set_bit in 2.4 and is thus okay. Note: Although it's been widely popular, there is no need to use cpu_to_le32 when converting from set_bit. A generic hash filter calculator might be helpful. Most drivers get it right, but the workings of the hardware mc filters and the bit trickery in all those functions calls for at least one _documented_ version. IMHO, anyway. Roger From sfeldma@pobox.com Sun Jun 6 17:03:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 17:03:13 -0700 (PDT) Received: from out001.verizon.net ([206.46.170.140]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5703Agi021261 for ; Sun, 6 Jun 2004 17:03:10 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out001.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040607000310.FDJY1464.out001.verizon.net@[192.168.0.79]>; Sun, 6 Jun 2004 19:03:10 -0500 Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time From: Scott Feldman Reply-To: sfeldma@pobox.com To: Tim Mattox Cc: Scott Feldman , netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, jgarzik@pobox.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1086566591.3721.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 06 Jun 2004 17:03:11 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [4.5.57.153] at Sun, 6 Jun 2004 19:03:09 -0500 X-archive-position: 5670 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: 1311 Lines: 33 > Have you considered how this interacts with multiple e100's bonded > together with Linux channel bonding? > I've CC'd the bonding developer mailing list to flush out any more > opinions on this. No. But if there is an issue between NAPI and bonding, that's something to solve between NAPI and bonding but not the nic driver. > I have yet to set up a good test system, but my impression has been > that NAPI and channel bonding would lead to lots of packet re-ordering > load for the CPU that could outweigh the interrupt load savings. > Does anyone have experience with this? re-ordering or dropped? > Also, depending on the setting of /proc/sys/net/ipv4/tcp_reordering > the TCP stack might do aggressive NACKs because of a false-positive on > dropped packets due to the large reordering that could occur with > NAPI and bonding combined. I guess I don't see the bonding angle. How does inserting a SW FIFO between the nic HW and the softirq thread make things better for bonding? > In short, unless there has been study on this, I would suggest not yet > removing support for non-NAPI mode on any network driver. fedora core 2's default is e100-NAPI, so we're getting good test coverage there without bonding. tg3 has used NAPI only for some time, and I'm sure it's used with bonding. -scott From tmattox@engr.uky.edu Sun Jun 6 18:51:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 18:51:32 -0700 (PDT) Received: from spitfire.ecc.engr.uky.edu (spitfire.ecc.engr.uky.edu [128.163.144.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i571pPgi023122 for ; Sun, 6 Jun 2004 18:51:28 -0700 Received: from kaos.ee.engr.uky.edu ([128.163.147.210] helo=[192.168.0.186]) by spitfire.ecc.engr.uky.edu with esmtp (Exim 4.34) id 1BX9IJ-0000Lh-W6; Sun, 06 Jun 2004 21:51:25 -0400 In-Reply-To: <1086566591.3721.54.camel@localhost.localdomain> References: <1086566591.3721.54.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2DF80C45-B825-11D8-9557-000393652100@engr.uky.edu> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, Scott Feldman , jgarzik@pobox.com From: Tim Mattox Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time Date: Sun, 6 Jun 2004 21:51:23 -0400 To: sfeldma@pobox.com X-Mailer: Apple Mail (2.618) X-archive-position: 5671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@engr.uky.edu Precedence: bulk X-list: netdev Content-Length: 5711 Lines: 120 Please excuse the length of this e-mail. I will attempt to explain the potential problem between NAPI and bonding with an example below. And the only reason I say "potential" is that I have deliberately avoided building clusters with this configuration and have not seen it "in the wild" personally. I've read about this problem on the beowulf mailing list, usually in conjunction with people trying to bond GigE NICs. I will soon have a cluster that can be easily switched to various modes on it's network, including simple bonding, and I should be able to directly test this myself in my lab. The problem is caused by the order packets are delivered to the TCP stack on the receiving machine. In normal round-robin bonding mode, the packets are sent out one per NIC in the bond. For simplicity sake, lets say we have two NICs in a bond, eth0 and eth1. When sending packets, eth0 will handle all the even packets, and eth1 all the odd packets. Similarly when receiving, eth0 would get all the even packets, and eth1 all the odd packets from a particular TCP stream. With NAPI (or other interrupt mitigation techniques) the receiving machine will process multiple packets in a row from a single NIC, before getting packets from another NIC. In the above example, eth0 would receive packets 0, 2, 4, 6, etc. and pass them to the TCP layer. Followed by eth1's packets 1, 3, 5, 7, etc. The specific number of out-of-order packets received in a row would depend on many factors. The TCP layer would need to reorder the packets from something like 0, 2, 4, 6, 1, 3, 5, 7 or something like 0, 2, 4, 1, 3, 5, 6, 7. With many possible variations. Before NAPI (and hardware interrupt mitigation schemes), bonding would work without causing this re-ordering, since each packet would arrive and be enqueued to the TCP stack in the order of arrival, which in a well designed network would match the transmission order. Sure, if your network randomly delayed packets then things would get out of order, but in the HPC community which uses bonding, the two network paths would normally be made identical, and possibly with only a single switch between source and destination NICs. If there was congestion delays in one path and not in another, then the HPC network/program had more serious problems. I don't want to slow the progress of Linux networking development. I was objecting to the removal of a feature to e100 that already has working code and that was, AFAIK, necessary for the performance enhancement of bonding. If the overhead of re-ordering the packets is not significant, and if simply increasing the value of /proc/sys/net/ipv4/tcp_reordering will allow TCP to "chill" and not send negative ACKs when it sees packets this much out of order, than sure, remove the non-NAPI support. I will attempt to re-locate the specific examples discussed on the beowulf mailing list, but I don't have those URLs handy. On Jun 6, 2004, at 8:03 PM, Scott Feldman wrote: >> Have you considered how this interacts with multiple e100's bonded >> together with Linux channel bonding? >> I've CC'd the bonding developer mailing list to flush out any more >> opinions on this. > > No. But if there is an issue between NAPI and bonding, that's > something > to solve between NAPI and bonding but not the nic driver. There may yet need to be more bonding code put in the receive path to deal with this re-ordering problem. Or possibly a configuration option to NAPI that works across various NIC drivers. But I hope not. Any bonding developers have ideas on how to mitigate this problem? >> I have yet to set up a good test system, but my impression has been >> that NAPI and channel bonding would lead to lots of packet re-ordering >> load for the CPU that could outweigh the interrupt load savings. >> Does anyone have experience with this? > > re-ordering or dropped? This re-ordering problem will show up without any actual packet loss. >> Also, depending on the setting of /proc/sys/net/ipv4/tcp_reordering >> the TCP stack might do aggressive NACKs because of a false-positive on >> dropped packets due to the large reordering that could occur with >> NAPI and bonding combined. > > I guess I don't see the bonding angle. How does inserting a SW FIFO > between the nic HW and the softirq thread make things better for > bonding? I'm not sure I understand your question. The tcp_reordering parameter is supposed to control the amount of out-of-order packets the receiving TCP stack sees before issuing pre-emptive negative ACKs to the sender. (To avoid waiting for the TCP resend timer to expire.) This was an optimization that works well in most situations where packet re-ordering was a strong indication of a dropped packet. Such extra NACKs, and the resulting unnecessary retransmits, would be quite detrimental to performance in a bonded network setup that was not actually dropping packets. >> In short, unless there has been study on this, I would suggest not yet >> removing support for non-NAPI mode on any network driver. > > fedora core 2's default is e100-NAPI, so we're getting good test > coverage there without bonding. tg3 has used NAPI only for some time, > and I'm sure it's used with bonding. > > -scott I have NO problems with NAPI itself, I think it's a wonderful development. I would even advocate for making NAPI the default across the board. But for bonding, until I see otherwise, I want to be able to not use NAPI. As I indicated, I will have a new cluster that I can directly test this NAPI vs Bonding issue very soon. -- Tim Mattox - tmattox@engr.uky.edu - http://homepage.mac.com/tmattox/ http://aggregate.org/KAOS/ - http://advogato.org/person/tmattox/ From dave@thedillows.org Sun Jun 6 19:29:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 19:29:58 -0700 (PDT) Received: from smtp2.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i572Ttgi023983 for ; Sun, 6 Jun 2004 19:29:56 -0700 Received: (qmail 13889 invoked from network); 7 Jun 2004 02:29:54 -0000 Received: from unknown (HELO ori.thedillows.org) (69.1.45.93) by smtp3.knology.net with SMTP; 7 Jun 2004 02:29:54 -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 i572Tr51018073; Sun, 6 Jun 2004 22:29:54 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i572TrIk018071; Sun, 6 Jun 2004 22:29:53 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: [0/3] mc_filter on big-endian arch From: David Dillow To: Roger Luethi Cc: Jeff Garzik , Andrew Morton , Netdev In-Reply-To: <20040606165322.GA13247@k3.hellgate.ch> References: <20040606165322.GA13247@k3.hellgate.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1086575392.4731.9.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Jun 2004 22:29:52 -0400 X-archive-position: 5672 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: 697 Lines: 15 On Sun, 2004-06-06 at 12:53, Roger Luethi wrote: > A bunch of other drivers are affected, too. I'll post a patch for > 2.6 atp, winbond, and tulip_core (typhoon could be okay at first > glance). Those are entirely untested due to lack of hardware. I think typhoon's OK -- I calculate the filter on the host, and then do a cpu_to_le32() on the final values, since the processor on the NIC is in little-endian mode. However, I've never tested it. I'll be happy to do so, if someone will point me to appropriate code -- I've got an Ultra5 as well, so I can test both big and little endian machines. Otherwise, I'll test it when I get around to writing something, or someone reports a bug. :) Dave From jgarzik@pobox.com Sun Jun 6 19:33:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 19:33:44 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i572Xegi024315 for ; Sun, 6 Jun 2004 19:33:41 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BX9xD-0005oK-6a; Mon, 07 Jun 2004 03:33:39 +0100 Message-ID: <40C3D3F6.6010103@pobox.com> Date: Sun, 06 Jun 2004 22:33:26 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Mattox CC: sfeldma@pobox.com, netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, Scott Feldman Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time References: <1086566591.3721.54.camel@localhost.localdomain> <2DF80C45-B825-11D8-9557-000393652100@engr.uky.edu> In-Reply-To: <2DF80C45-B825-11D8-9557-000393652100@engr.uky.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5673 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: 2932 Lines: 65 Tim Mattox wrote: > The problem is caused by the order packets are delivered to the TCP > stack on the receiving machine. In normal round-robin bonding mode, > the packets are sent out one per NIC in the bond. For simplicity > sake, lets say we have two NICs in a bond, eth0 and eth1. When > sending packets, eth0 will handle all the even packets, and eth1 all > the odd packets. Similarly when receiving, eth0 would get all > the even packets, and eth1 all the odd packets from a particular > TCP stream. > > With NAPI (or other interrupt mitigation techniques) the > receiving machine will process multiple packets in a row from a > single NIC, before getting packets from another NIC. In the > above example, eth0 would receive packets 0, 2, 4, 6, etc. > and pass them to the TCP layer. Followed by eth1's > packets 1, 3, 5, 7, etc. The specific number of out-of-order > packets received in a row would depend on many factors. > > The TCP layer would need to reorder the packets from something > like 0, 2, 4, 6, 1, 3, 5, 7 or something > like 0, 2, 4, 1, 3, 5, 6, 7. With many possible variations. Ethernet drivers have _always_ processed multiple packets per interrupt, since before the days of NAPI, and before the days of hardware mitigation. Therefore, this is mainly an argument against using overly simplistic load balancing schemes that _create_ this problem :) It's much smarter to load balance based on flows, for example. I think the ALB mode does this? You appear to be making the incorrect assumption that packets sent in this simplistic, round-robin manner could ever _hope_ to arrive in-order at the destination. Any number of things serve gather packets into bursts: net stack TX queue, hardware DMA ring, hardware FIFO, remote h/w FIFO, remote hardware DMA ring, remote softirq. > I don't want to slow the progress of Linux networking development. > I was objecting to the removal of a feature to e100 that already has > working code and that was, AFAIK, necessary for the performance > enhancement of bonding. No, just don't use a bonding mode that kills performance. It has nothing to do with NAPI. As I said, ethernet drivers have been processing runs of packets per irq / softirq for ages and ages. This isn't new with NAPI, to be sure. > I have NO problems with NAPI itself, I think it's a wonderful development. > I would even advocate for making NAPI the default across the board. > But for bonding, until I see otherwise, I want to be able to not use NAPI. > As I indicated, I will have a new cluster that I can directly test this > NAPI vs Bonding issue very soon. As Scott indicated, people use bonding with tg3 (unconditional NAPI) all time. Further, I hope you're not doing something silly like trying to load balance on the _same_ ethernet. If you are, that's a signal that deeper problems exist -- you should be able to do wire speed with one NIC. Jeff From jm@jm.kir.nu Sun Jun 6 19:35:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 19:35:16 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i572ZCgi024625 for ; Sun, 6 Jun 2004 19:35:12 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BX9yR-0002iX-AT; Sun, 06 Jun 2004 19:34:55 -0700 Date: Sun, 6 Jun 2004 19:34:55 -0700 From: Jouni Malinen To: Jean Tourrilhes Cc: netdev@oss.sgi.com Subject: RFC: Linux wireless extensions and WPA support Message-ID: <20040607023455.GA10424@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 5674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 9794 Lines: 289 I started working on WPA extension for the Linux wireless extensions based on our earlier discussion. This patch file for V16 shows my current work version. It is not yet ready to be merged into any tree and is here mainly to allow review of the changes and generate some discussion (and well, to describe the changes without me having to write a long email doing that ;-). This has not yet been tested, but I'm starting to add support for it into the wireless-2.6 version of Host AP driver and wpa_supplicant. I'll make an updated patch available once everything seems to be working. To avoid using much more ioctl numbers, I extended the previously defined SIOCSIWENCODE/SIOCGIWENCODE and SIOCSIWSCAN instead of defining new ioctls. Similarily, SIOCSIWAUTH/SIOCGIWAUTH uses one pair of ioctls to allow configuring multiple (4096) different parameters. supported_features bit field in struct iw_range will be used by the WPA Supplicant to determine which modes can be used with the current driver. Comments are very much welcome, especially from other authors of wireless device driver. I went through the wpa_supplicant driver interface and tried to include everything needed here. However, I did not yet verify whether some of the existing driver interfaces would benefit from additional fields in wireless extensions. ===== include/linux/wireless.h 1.9 vs edited ===== --- 1.9/include/linux/wireless.h Fri Apr 16 13:56:10 2004 +++ edited/include/linux/wireless.h Sun Jun 6 19:11:03 2004 @@ -1,7 +1,7 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 6.6.04 * * Authors : Jean Tourrilhes - HPL - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,20 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * ---------- + * - Add support for WPA/WPA2 + * - Add extended encoding configuration (IW_ENCODE_EXTENDED flag for + * SIOCSIWENCODE and SIOCGIWENCODE) + * - Larger IW_ENCODING_TOKEN_MAX (32 -> 256) + * - Add SIOCSIWGENIE/SIOCGIWGENIE + * - Add SIOCSIWMLME + * - Add struct iw_range bit field for listing supported driver features + * - Add optional parameter structure for SIOCSIWSCAN + * - Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA + * related parameters (extensible up to 4096 parameter values) + * - Add wireless events: IWEVPAIE, IWEVRSNIE, IWEVMICHAELMICFAILURE */ /**************************** CONSTANTS ****************************/ @@ -249,6 +263,17 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +/* Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WME) */ +#define SIOCSIWGENIE 0x8B2E /* set generic IE */ +#define SIOCGIWGENIE 0x8B2F /* get generic IE */ + +/* IEEE 802.11 MLME requests */ +#define SIOCSIWMLME 0x8B30 /* request MLME operation */ + +/* Authentication mode parameters */ +#define SIOCSIWAUTH 0x8B31 /* set authentication mode params */ +#define SIOCGIWAUTH 0x8B32 /* get authentication mode params */ + /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ /* These 16 ioctl are wireless device private. @@ -290,6 +315,11 @@ #define IWEVCUSTOM 0x8C02 /* Driver specific ascii string */ #define IWEVREGISTERED 0x8C03 /* Discovered a new node (AP mode) */ #define IWEVEXPIRED 0x8C04 /* Expired a node (AP mode) */ +#define IWEVWPAIE 0x8C05 /* WPA IE (scan results) */ +#define IWEVRSNIE 0x8C06 /* RSN IE (WPA2) (scan results) */ +#define IWEVMICHAELMICFAILURE 0x8C07 /* Michael MIC failure + * (struct iw_michaelmicfailure) + */ #define IWEVFIRST 0x8C00 @@ -357,7 +387,7 @@ #define IW_MAX_ENCODING_SIZES 8 /* Maximum size of the encoding token in bytes */ -#define IW_ENCODING_TOKEN_MAX 32 /* 256 bits (for now) */ +#define IW_ENCODING_TOKEN_MAX 256 /* Flags for encoding (along with the token) */ #define IW_ENCODE_INDEX 0x00FF /* Token index (if needed) */ @@ -369,6 +399,36 @@ #define IW_ENCODE_OPEN 0x2000 /* Accept non-encoded packets */ #define IW_ENCODE_NOKEY 0x0800 /* Key is write only, so not present */ #define IW_ENCODE_TEMP 0x0400 /* Temporary key */ +#define IW_ENCODE_EXTENDED 0x0200 /* Use extended data structure + * (struct iw_encode_ext) for + * encoding parameters */ + +#define IW_ENCODE_SEQ_MAX_SIZE 8 + +#define IW_ENCODE_ALG_NONE 0 +#define IW_ENCODE_ALG_WEP 1 +#define IW_ENCODE_ALG_TKIP 2 +#define IW_ENCODE_ALG_CCMP 3 + +/* IW_AUTH_WPA_VERSION values */ +#define IW_AUTH_VERSION_WPA_DISABLED 0 +#define IW_AUTH_VERSION_WPA 1 +#define IW_AUTH_VERSION_WPA2 2 + +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values */ +#define IW_CIPHER_NONE 0 +#define IW_CIPHER_WEP40 1 +#define IW_CIPHER_TKIP 2 +#define IW_CIPHER_CCMP 4 +#define IW_CIPHER_WEP104 5 + +/* IW_AUTH_KEY_MGMT values */ +#define IW_KEY_MGMT_802_1X 1 +#define IW_KEY_MGMT_PSK 2 + +/* IW_AUTH_80211_AUTH_ALG values (bit field) */ +#define IW_AUTH_ALG_OPEN_SYSTEM 0x00000001 +#define IW_AUTH_ALG_SHARED_KEY 0x00000002 /* Power management flags available (along with the value, if any) */ #define IW_POWER_ON 0x0000 /* No details... */ @@ -418,6 +478,32 @@ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Generic information element */ +#define IW_GENERIC_IE_MAX 256 + +/* MLME requests */ +#define IW_MLME_DEAUTH 0 +#define IW_MLME_DISASSOC 1 + +/* Bit field values for supported_features in struct iw_range */ +#define IW_FEATURE_WPA 0x00000001 +#define IW_FEATURE_WPA2 0x00000002 +#define IW_FEATURE_CIPHER_TKIP 0x00000004 +#define IW_FEATURE_CIPHER_CCMP 0x00000008 + +/* SIOCSIWAUTH/SIOCGIWAUTH flags */ +#define IW_AUTH_INDEX 0x0FFF +#define IW_AUTH_FLAGS 0xF000 +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) */ +#define IW_AUTH_WPA_VERSION 0 +#define IW_AUTH_PAIRWISE_CIPHER 1 +#define IW_AUTH_GROUP_CIPHER 2 +#define IW_AUTH_KEY_MGMT 3 +#define IW_AUTH_TKIP_COUNTERMEASURES 4 +#define IW_AUTH_DROP_UNENCRYPTED 5 +#define IW_AUTH_80211_AUTH_ALG 6 + + /****************************** TYPES ******************************/ /* --------------------------- SUBTYPES --------------------------- */ @@ -507,6 +593,59 @@ struct iw_quality high; /* High threshold */ }; +/* + * Optional data for scan request + */ +struct iw_scan_req +{ + /* Use this SSID if IW_SCAN_THIS_ESSID flag is used instead of using + * the current SSID. This allows scan requests for specific SSID + * without having to change the current SSID and potentially breaking + * the current association. */ + __u8 ssid_len; + __u8 ssid[IW_ESSID_MAX_SIZE]; +}; + +/* + * Extended data structure for get/set encoding (this is used if + * IW_ENCODE_EXTENDED flag is set). + */ +struct iw_encode_ext +{ +#define IW_ENCODE_EXT_TX_SEQ_VALID 0x00000001 +#define IW_ENCODE_EXT_RX_SEQ_VALID 0x00000002 +#define IW_ENCODE_EXT_GROUP_KEY 0x00000004 + __u32 ext_flags; + __u8 tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + __u8 rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + __u16 alg; /* IW_ENCODE_ALG_* */ + struct sockaddr addr; /* ff:ff:ff:ff:ff:ff for broadcast/multicast + * (group) keys or unicast address for + * individual keys */ + __u16 key_len; + __u8 key[0]; +}; + +struct iw_mlme +{ + __u16 cmd; /* IW_MLME_* */ + __u16 reason_code; + struct sockaddr addr; +}; + +struct iw_michaelmicfailure +{ +#define IW_MICFAILURE_KEY_ID 0x00000003 /* Key ID 0..3 */ +#define IW_MICFAILURE_GROUP 0x00000004 +#define IW_MICFAILURE_PAIRWISE 0x00000008 +#define IW_MICFAILURE_STAKEY 0x00000010 +#define IW_MICFAILURE_COUNT 0x00000060 /* 1 or 2 (0 = count not supported) + */ + __u32 flags; + struct sockaddr src_addr; + __u8 tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ +}; + /* ------------------------ WIRELESS STATS ------------------------ */ /* * Wireless statistics (used for /proc/net/wireless) @@ -685,6 +824,8 @@ struct iw_freq freq[IW_MAX_FREQUENCIES]; /* list */ /* Note : this frequency list doesn't need to fit channel numbers, * because each entry contain its channel index */ + + __u32 supported_features; /* IW_FEATURE_* bit field */ }; /* ===== net/core/wireless.c 1.15 vs edited ===== --- 1.15/net/core/wireless.c Sun Sep 28 15:29:53 2003 +++ edited/net/core/wireless.c Sun Jun 6 18:43:31 2004 @@ -189,6 +189,8 @@ }, [SIOCSIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, + .token_size = sizeof(struct iw_scan_req), + .max_tokens = 1, }, [SIOCGIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, @@ -263,6 +265,27 @@ .header_type = IW_HEADER_TYPE_PARAM, }, [SIOCGIWPOWER - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCGIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCSIWMLME - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = sizeof(struct iw_mlme), + .max_tokens = 1, + }, + [SIOCSIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCGIWAUTH - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, }, }; -- Jouni Malinen PGP id EFC895FA From davem@redhat.com Sun Jun 6 20:18:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 20:18:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i573IKgi025698 for ; Sun, 6 Jun 2004 20:18:20 -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 i573IFi5008580; Sun, 6 Jun 2004 23:18:15 -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 i573IF022518; Sun, 6 Jun 2004 23:18:15 -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 i573I3HY000861; Sun, 6 Jun 2004 23:18:04 -0400 Date: Sun, 6 Jun 2004 20:15:27 -0700 From: "David S. Miller" To: hadi@znyx.com Cc: laforge@netfilter.org, netdev@oss.sgi.com Subject: Re: small netfilter cleanup Message-Id: <20040606201527.15840046.davem@redhat.com> In-Reply-To: <1086434538.1590.16.camel@jzny.localdomain> References: <1086434538.1590.16.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5675 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: 714 Lines: 22 On 05 Jun 2004 07:22:19 -0400 Jamal Hadi Salim wrote: > I have been sitting on these patches for sometime now. > Harald, we did discuss this back when. > Attached patches for 2.4.26 and 2.6.6; both should patch > cleanly against pre 2.4.27 and 2.6.7 All applied, thanks guys. Jamal could you do me a huge favor and "-p1" root your patches? Ie. instead of: --- /usr/src/266/include/linux/netfilter.h 2004-05-09 22:32:37.000000000 -0400 +++ /usr/src/266-mod/include/linux/netfilter.h 2004-06-04 10:21:20.000000000 -0400 make it instead be: --- 266/include/linux/netfilter.h 2004-05-09 22:32:37.000000000 -0400 +++ 266-mod/include/linux/netfilter.h 2004-06-04 10:21:20.000000000 -0400 Thanks. From fubar@us.ibm.com Sun Jun 6 23:40:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 23:40:38 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i576eRgi001721 for ; Sun, 6 Jun 2004 23:40:34 -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.2) with ESMTP id i576dw18453848; Mon, 7 Jun 2004 02:39:58 -0400 Received: from death.nxdomain.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i576eqfK108454; Mon, 7 Jun 2004 02:40:53 -0400 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id i576drpf026564; Sun, 6 Jun 2004 23:39:53 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i576drvF026556; Sun, 6 Jun 2004 23:39:53 -0700 Message-Id: <200406070639.i576drvF026556@death.nxdomain.ibm.com> To: Jeff Garzik cc: Tim Mattox , sfeldma@pobox.com, netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, Scott Feldman Subject: Re: [Bonding-devel] Re: [PATCH 2.6] e100: use NAPI mode all the time In-Reply-To: Message from Jeff Garzik of "Sun, 06 Jun 2004 22:33:26 EDT." <40C3D3F6.6010103@pobox.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 06 Jun 2004 23:39:52 -0700 From: Jay Vosburgh X-archive-position: 5678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3545 Lines: 74 Jeff Garzik wrote: >Tim Mattox wrote: >> The problem is caused by the order packets are delivered to the TCP >> stack on the receiving machine. In normal round-robin bonding mode, >> the packets are sent out one per NIC in the bond. For simplicity >> sake, lets say we have two NICs in a bond, eth0 and eth1. When >> sending packets, eth0 will handle all the even packets, and eth1 all >> the odd packets. Similarly when receiving, eth0 would get all >> the even packets, and eth1 all the odd packets from a particular >> TCP stream. >Ethernet drivers have _always_ processed multiple packets per >interrupt, since before the days of NAPI, and before the days of >hardware mitigation. There was a discussion about this behavior (round-robin mode out of order delivery) on bonding-devel in February 2003. The archives can be found here: http://sourceforge.net/mailarchive/forum.php?forum_id=2094&max_rows=25&style=ultimate&viewmonth=200302 The messages on Feb 19 relate to the effects of packet coalescing, and Feb 17 to general out of order delivery problems. Somewhere in there are the results of some testing I did, and analysis of how tcp_ordering effects things. As I recall, I even used e100s for my testing, so it may be a fair apples to apples comparsion. When I tested this (on 4 100Mbps ethernets), even after adjusting tcp_reordering I could only get TCP single stream throughput of about 235 Mb/sec out of a theoretical 375 or so (400 minus about 6% for headers and whatnot). UDP would run in the mid to upper 300's, depending upon datagram size. The tests did not examine UDP delivery order. The round-robin mode will, for all practical purposes, always deliver some large percentage of packets out of order. You can fiddle with the tcp_reordering parameter to mitigate the effects to some degree, but there's no way it's going away entirely. I'm curious as to what types of systems the beowulf / HPC people (mentioned by Tim in an earlier message) are using that they don't see out of order problems with round robin, even without NAPI. >Therefore, this is mainly an argument against using overly simplistic >load balancing schemes that _create_ this problem :) It's much >smarter to load balance based on flows, for example. I think the ALB >mode does this? The round robin mode is unique in that it is the only mode that will attempt (however stupidly) to stripe single connections (flows) across multiple interfaces. The other (smarter) modes, 802.3ad, alb, and tlb, will try to keep particular connections generally on a particular interface (for 802.3ad, it's required by the standard to behave that way). This means that a given single TCP/IP connection won't get more than one interface worth of throughput. With round-robin, you can get more than one interface worth, but not very efficiently. >> I have NO problems with NAPI itself, I think it's a wonderful development. >> I would even advocate for making NAPI the default across the board. >> But for bonding, until I see otherwise, I want to be able to not use NAPI. >> As I indicated, I will have a new cluster that I can directly test this >> NAPI vs Bonding issue very soon. After taking into account the effects of delivering multiple packets per interrupt and the scheduling order of network device interrupts (potentially on different CPUs), I'm not really sure there's much room for NAPI to make round-robin any worse than it already is. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From sfr@canb.auug.org.au Sun Jun 6 23:43:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jun 2004 23:43:32 -0700 (PDT) Received: from pcug.org.au (supreme.pcug.org.au [203.10.76.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i576hPgi002496 for ; Sun, 6 Jun 2004 23:43:26 -0700 Received: from localhost (localhost [127.0.0.1]) by pcug.org.au (8.12.9/8.12.9/TIP-2.39) with SMTP id i576hDOe008565; Mon, 7 Jun 2004 16:43:13 +1000 (EST) Date: Mon, 7 Jun 2004 16:43:12 +1000 From: Stephen Rothwell To: Andrew Morton , Linus Cc: Jeff Garzik , ppc64-dev , netdev@oss.sgi.com Subject: [PATCH] PPC64 iSeries virtual ethernet proc files Message-Id: <20040607164312.258a9f99.sfr@canb.auug.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__7_Jun_2004_16_43_13_+1000_rI7AdqH.jktRpZ4z" X-archive-position: 5680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfr@canb.auug.org.au Precedence: bulk X-list: netdev Content-Length: 3915 Lines: 154 --Signature=_Mon__7_Jun_2004_16_43_13_+1000_rI7AdqH.jktRpZ4z Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Andrew, From: David Gibson This patch just adds back some of the iserires_veth proc files to provide information to user space (particularly Kudzu) to allow the virtual ethernets to be discovered. These files existed in a 2.4 version of this driver that was shipped by some distros. Signed-off-by: Stephen Rothwell -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN 2.6.7-rc2-bk7/drivers/net/iseries_veth.c 2.6.7-rc2-bk7.veth.proc.1/drivers/net/iseries_veth.c --- 2.6.7-rc2-bk7/drivers/net/iseries_veth.c 2004-06-07 13:35:47.000000000 +1000 +++ 2.6.7-rc2-bk7.veth.proc.1/drivers/net/iseries_veth.c 2004-06-07 15:28:40.000000000 +1000 @@ -165,6 +165,7 @@ static HvLpIndex this_lp; static struct veth_lpar_connection *veth_cnx[HVMAXARCHITECTEDLPS]; /* = 0 */ static struct net_device *veth_dev[HVMAXARCHITECTEDVIRTUALLANS]; /* = 0 */ +struct proc_dir_entry *veth_proc_root; /* = NULL */ static int veth_start_xmit(struct sk_buff *skb, struct net_device *dev); static void veth_recycle_msg(struct veth_lpar_connection *, struct veth_msg *); @@ -1328,6 +1329,91 @@ } /* + * procfs code (used by userspace for discovery) + */ +static int proc_veth_dump_port(char *page, char **start, off_t off, int count, + int *eof, void *data) +{ + char *out = page; + struct net_device *dev = data; + struct veth_port *port = dev->priv; + long len; + int i; + + BUG_ON(port == NULL); + + out += sprintf(out, "Net device name:\t%s\n", dev->name); + out += sprintf(out, "Address:\t%012lX\n", port->mac_addr >> 16); + + read_lock_irq(&port->mcast_gate); + out += sprintf(out, "Promiscuous:\t%d\n", port->promiscuous); + out += sprintf(out, "All multicast:\t%d\n", port->all_mcast); + out += sprintf(out, "Number multicast:\t%d\n", port->num_mcast); + + for (i = 0; i < port->num_mcast; ++i) + out += sprintf(out, " %012lX\n", port->mcast_addr[i] >> 16); + read_unlock_irq(&port->mcast_gate); + + len = (out - page) - off; + if (len < count) + *eof = 1; + else + len = count; + + if (len <= 0) + len = 0; + else + *start = page + off; + return len; +} + +static void veth_proc_init(void) +{ + int i; + + veth_proc_root = proc_mkdir("iSeries/veth", NULL); + if (veth_proc_root == NULL) + return; + + for (i = 0; i < HVMAXARCHITECTEDVIRTUALLANS; i++) { + struct proc_dir_entry *ent; + char name[10]; + + if (veth_dev[i] == NULL) + continue; + + sprintf(name, "veth%d", i); + ent = create_proc_entry(name, S_IFREG | S_IRUSR, + veth_proc_root); + if (ent == NULL) + return; + + ent->nlink = 1; + ent->owner = THIS_MODULE; + ent->data = veth_dev[i]; + ent->read_proc = proc_veth_dump_port; + ent->write_proc = NULL; + } +} + +static void veth_proc_delete(void) +{ + int i; + + for (i = 0; i < HVMAXARCHITECTEDVIRTUALLANS; i++) { + char name[10]; + + if (veth_dev[i] == NULL) + continue; + + sprintf(name, "veth%d", i); + remove_proc_entry(name, veth_proc_root); + } + + remove_proc_entry("iSeries/veth", NULL); +} + +/* * Module initialization/cleanup */ @@ -1335,6 +1421,8 @@ { int i; + veth_proc_delete(); + for (i = 0; i < HVMAXARCHITECTEDLPS; ++i) veth_destroy_connection(i); @@ -1394,6 +1482,8 @@ if (veth_cnx[i]) veth_kick_statemachine(veth_cnx[i]); + veth_proc_init(); + return 0; } module_init(veth_module_init); --Signature=_Mon__7_Jun_2004_16_43_13_+1000_rI7AdqH.jktRpZ4z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxA6BFG47PeJeR58RAiYFAJ9Lu7T3X9XuAyz7AxQXC/c1zBOIZwCg13/K RRnDHqJY7GNOR/6682jTN0U= =NID2 -----END PGP SIGNATURE----- --Signature=_Mon__7_Jun_2004_16_43_13_+1000_rI7AdqH.jktRpZ4z-- From rl@hellgate.ch Mon Jun 7 00:55:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 00:55:38 -0700 (PDT) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i577tYgi007607 for ; Mon, 7 Jun 2004 00:55:35 -0700 Received: from k3.hellgate.ch (83.76.121.213) by mail2.bluewin.ch (Bluewin AG 7.0.028) id 40A46896002A6922; Sun, 6 Jun 2004 16:53:32 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id A74488B29E8; Sun, 6 Jun 2004 18:53:31 +0200 (CEST) Date: Sun, 6 Jun 2004 18:53:31 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [3/3][PATCH 2.4] via-rhine: fix mc_filter on big-endian arch Message-ID: <20040606165331.GA14002@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 745 Lines: 19 A.J. from VIA Networking Technologies noticed that via-rhine is using cpu_to_le32() when preparing mc_filter hashes. This breaks Rhine hardware multicast filters on big-endian architectures. Please apply. Signed-off-by: Roger Luethi --- 2.4-pre/drivers/net/via-rhine.c.orig 2004-06-06 18:12:07.825350069 +0200 +++ 2.4-pre/drivers/net/via-rhine.c 2004-06-06 18:08:45.834623930 +0200 @@ -1748,7 +1748,7 @@ i++, mclist = mclist->next) { int bit_nr = ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26; - mc_filter[bit_nr >> 5] |= cpu_to_le32(1 << (bit_nr & 31)); + mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31); } writel(mc_filter[0], ioaddr + MulticastFilter0); writel(mc_filter[1], ioaddr + MulticastFilter1); From Gary.Spiess@intermec.com Mon Jun 7 02:36:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 02:36:23 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i579aKgi013028 for ; Mon, 7 Jun 2004 02:36:20 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id OAA00283; Fri, 4 Jun 2004 14:51:59 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i54Mr6KJ023531; Fri, 4 Jun 2004 17:53:06 -0500 Message-ID: <200406041451590078.0BC23855@136.179.85.112> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 04 Jun 2004 14:51:59 -0500 From: "Gary N Spiess" To: netdev@oss.sgi.com Cc: manfred@colorfullife.com Subject: [PATCH] natsemi update 1/4 Use assigned MAC address Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_108637871916827=_" X-archive-position: 5684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@intermec.com Precedence: bulk X-list: netdev Content-Length: 6094 Lines: 123 --=====_108637871916827=_ Content-Type: multipart/alternative; boundary="=====_10863787199961=_" --=====_10863787199961=_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Jeff, This is the first of a series of patches needed to support our product= using the DP83815. This patch accepts the MAC address as a parameter because our= implementation does not have an EEPROM. I tried to upgrade to the new= module_param_array() macro, but couldn't find a tutorial on the new param= scheme. To get things working for our development, I use a __setup()= wrapper to get "ethaddr=3D" from the linux command line. Gary oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 --=====_10863787199961=_ Content-Type: text/html; charset="us-ascii"

Jeff,

This is the first of a series of patches needed to support our product using the DP83815.

This patch accepts the MAC address as a parameter because our implementation does not have an EEPROM.  I tried to upgrade to the new module_param_array() macro, but couldn't find a tutorial on the new param scheme.  To get things working for our development, I use a __setup() wrapper to get "ethaddr=" from the linux command line.

Gary

 
 oooooooooooooooooooooooooooooooooooooooooooooooooo
 Gary Spiess (Gary.Spiess@Intermec.com)
 MobileLan Wireless Products Group, Intermec Technology Corp
 voice: 319 369-3580  fax: 319 369-3804
--=====_10863787199961=_-- --=====_108637871916827=_ Content-Type: application/octet-stream; name="natsemi-2.6.6-1.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="natsemi-2.6.6-1.patch" LS0tIGxpbnV4LTIuNi42L2RyaXZlcnMvbmV0L25hdHNlbWkuYwkyMDA0LTA2 LTAyIDEzOjMxOjM3LjAwMDAwMDAwMCAtMDUwMAorKysgbGludXgvZHJpdmVy cy9uZXQvbmF0c2VtaS5jCTIwMDQtMDYtMDIgMTY6NTY6MzguMDAwMDAwMDAw IC0wNTAwCkBAIC0xNDcsNiArMTQ3LDcgQEAKIAogI2luY2x1ZGUgPGxpbnV4 L2NvbmZpZy5oPgogI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgorI2luY2x1 ZGUgPGxpbnV4L21vZHVsZXBhcmFtLmg+CiAjaW5jbHVkZSA8bGludXgva2Vy bmVsLmg+CiAjaW5jbHVkZSA8bGludXgvc3RyaW5nLmg+CiAjaW5jbHVkZSA8 bGludXgvdGltZXIuaD4KQEAgLTIwOSw2ICsyMTAsOCBAQAogI2RlZmluZSBN QVhfVU5JVFMgOAkJLyogTW9yZSBhcmUgc3VwcG9ydGVkLCBsaW1pdCBvbmx5 IG9uIG9wdGlvbnMgKi8KIHN0YXRpYyBpbnQgb3B0aW9uc1tNQVhfVU5JVFNd Owogc3RhdGljIGludCBmdWxsX2R1cGxleFtNQVhfVU5JVFNdOworc3RhdGlj IGNoYXIgKmV0aGFkZHJbTUFYX1VOSVRTXSA9IHtOVUxMLCB9Oworc3RhdGlj IGludCBldGhhZGRyX251bSA9IDA7CiAKIC8qIE9wZXJhdGlvbmFsIHBhcmFt ZXRlcnMgdGhhdCBhcmUgc2V0IGF0IGNvbXBpbGUgdGltZS4gKi8KIApAQCAt MjU2LDYgKzI1OSw3IEBACiBNT0RVTEVfUEFSTShyeF9jb3B5YnJlYWssICJp Iik7CiBNT0RVTEVfUEFSTShvcHRpb25zLCAiMS0iIF9fTU9EVUxFX1NUUklO RyhNQVhfVU5JVFMpICJpIik7CiBNT0RVTEVfUEFSTShmdWxsX2R1cGxleCwg IjEtIiBfX01PRFVMRV9TVFJJTkcoTUFYX1VOSVRTKSAiaSIpOworbW9kdWxl X3BhcmFtX2FycmF5KGV0aGFkZHIsIGNoYXJwLCBldGhhZGRyX251bSwgU19J UlVHTyk7CiBNT0RVTEVfUEFSTV9ERVNDKG1heF9pbnRlcnJ1cHRfd29yaywg CiAJIkRQODM4MXggbWF4aW11bSBldmVudHMgaGFuZGxlZCBwZXIgaW50ZXJy dXB0Iik7CiBNT0RVTEVfUEFSTV9ERVNDKG10dSwgIkRQODM4MXggTVRVIChh bGwgYm9hcmRzKSIpOwpAQCAtMjY1LDYgKzI2OSw3IEBACiBNT0RVTEVfUEFS TV9ERVNDKG9wdGlvbnMsIAogCSJEUDgzODF4OiBCaXRzIDAtMzogbWVkaWEg dHlwZSwgYml0IDE3OiBmdWxsIGR1cGxleCIpOwogTU9EVUxFX1BBUk1fREVT QyhmdWxsX2R1cGxleCwgIkRQODM4MXggZnVsbCBkdXBsZXggc2V0dGluZyhz KSAoMSkiKTsKK01PRFVMRV9QQVJNX0RFU0MoZXRoYWRkciwgIkRQODM4MXgg TUFDIGFkZHIocykgeHg6eHg6eHg6eHg6eHg6eHgiKTsKIAogLyoKIAkJCQlU aGVvcnkgb2YgT3BlcmF0aW9uCkBAIC03NzYsMTMgKzc4MSwyMiBAQAogCQln b3RvIGVycl9pb3JlbWFwOwogCX0KIAotCS8qIFdvcmsgYXJvdW5kIHRoZSBk cm9wcGVkIHNlcmlhbCBiaXQuICovCi0JcHJldl9lZWRhdGEgPSBlZXByb21f cmVhZChpb2FkZHIsIDYpOwotCWZvciAoaSA9IDA7IGkgPCAzOyBpKyspIHsK LQkJaW50IGVlZGF0YSA9IGVlcHJvbV9yZWFkKGlvYWRkciwgaSArIDcpOwot CQlkZXYtPmRldl9hZGRyW2kqMl0gPSAoZWVkYXRhIDw8IDEpICsgKHByZXZf ZWVkYXRhID4+IDE1KTsKLQkJZGV2LT5kZXZfYWRkcltpKjIrMV0gPSBlZWRh dGEgPj4gNzsKLQkJcHJldl9lZWRhdGEgPSBlZWRhdGE7CisJaWYgKGZpbmRf Y250IDwgZXRoYWRkcl9udW0pCisJeworCQlpbnQgaSwgYVs2XTsKKwkJc3Nj YW5mKGV0aGFkZHJbZmluZF9jbnRdLCAiJTJ4OiUyeDolMng6JTJ4OiUyeDol MngiLAorCQkJJmFbMF0sICZhWzFdLCAmYVsyXSwgJmFbM10sICZhWzRdLCAm YVs1XSk7CisJCWZvciAoaSA9IDY7IGktLTsgKQorCQkJZGV2LT5kZXZfYWRk cltpXSA9ICh1bnNpZ25lZCBjaGFyKWFbaV07CisJfSBlbHNlIHsKKwkJLyog V29yayBhcm91bmQgdGhlIGRyb3BwZWQgc2VyaWFsIGJpdC4gKi8KKwkJcHJl dl9lZWRhdGEgPSBlZXByb21fcmVhZChpb2FkZHIsIDYpOworCQlmb3IgKGkg PSAwOyBpIDwgMzsgaSsrKSB7CisJCQlpbnQgZWVkYXRhID0gZWVwcm9tX3Jl YWQoaW9hZGRyLCBpICsgNyk7CisJCQlkZXYtPmRldl9hZGRyW2kqMl0gPSAo ZWVkYXRhIDw8IDEpICsgKHByZXZfZWVkYXRhID4+IDE1KTsKKwkJCWRldi0+ ZGV2X2FkZHJbaSoyKzFdID0gZWVkYXRhID4+IDc7CisJCQlwcmV2X2VlZGF0 YSA9IGVlZGF0YTsKKwkJfQogCX0KIAogCWRldi0+YmFzZV9hZGRyID0gaW9h ZGRyOwpAQCAtMjY5Niw2ICsyNzEyLDI4IEBACiAJcGNpX3VucmVnaXN0ZXJf ZHJpdmVyICgmbmF0c2VtaV9kcml2ZXIpOwogfQogCisvKiBwZXJtaXQgZXRo YWRkciB0byBiZSBzcGVjaWZpZWQgaW4gdGhlIGxpbnV4IGNvbW1hbmQgbGlu ZSBhcworICogYm9vdGFyZ3M9ImV0aGFkZHI9eHg6eHg6eHg6eHg6eHg6eHgi LgorICovCitzdGF0aWMgaW50IF9faW5pdCBnZXRfbWFjX2FkZHIoY2hhciAq c3RyKQoreworCS8qIGNhbid0IGRlYWwgd2l0aCBtdWx0aXBsZSBkZWZpbml0 aW9ucyAqLworCWlmICghZXRoYWRkcl9udW0pCisJeworCQlzdGF0aWMgdW5z aWduZWQgY2hhciB0ZW1wZXRoYWRkclsxOF07CisKKwkJLyogVW5zYWZlIHRv IGp1c3Qgc2F2ZSB0aGUgcG9pbnRlcj8gIEknbGwgbWFrZSBhIGNvcHkgKi8K KwkJc3RybmNweSh0ZW1wZXRoYWRkciwgc3RyLCBzaXplb2YodGVtcGV0aGFk ZHIpKTsKKwkJdGVtcGV0aGFkZHJbc2l6ZW9mKHRlbXBldGhhZGRyKS0xXSA9 IDA7CisKKwkJLyogRG8gd2hhdCBJIHRoaW5rIG1vZHVsZV9wYXJhbV9hcnJh eSgpIHNob3VsZCBkbyAqLworCQlldGhhZGRyW2V0aGFkZHJfbnVtKytdID0g dGVtcGV0aGFkZHI7CisJfQorCXJldHVybiAwOworfQorCitfX3NldHVwKCJl dGhhZGRyPSIsIGdldF9tYWNfYWRkcik7CisKIG1vZHVsZV9pbml0KG5hdHNl bWlfaW5pdF9tb2QpOwogbW9kdWxlX2V4aXQobmF0c2VtaV9leGl0X21vZCk7 CiAK --=====_108637871916827=_-- From Gary.Spiess@intermec.com Mon Jun 7 06:02:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 06:02:21 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57D2Ggi009312 for ; Mon, 7 Jun 2004 06:02:17 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id OAA00390; Fri, 4 Jun 2004 14:55:29 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i54MumKJ023544; Fri, 4 Jun 2004 17:56:48 -0500 Message-ID: <200406041455290031.0BC56C76@136.179.85.112> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 04 Jun 2004 14:55:29 -0500 From: "Gary N Spiess" To: netdev@oss.sgi.com Cc: manfred@colorfullife.com Subject: [PATCH] natsemi update 3/4 External PHY operation Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_10863789292995=_" X-archive-position: 5686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@intermec.com Precedence: bulk X-list: netdev Content-Length: 12890 Lines: 234 --=====_10863789292995=_ Content-Type: multipart/alternative; boundary="=====_108637892911942=_" --=====_108637892911942=_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Jeff, This is the third of a series of patches needed to support our product= using the DP83815. This patch permits operation of an external PHY. Updates the mdio_read and= mdio_write functions to permit actual MII operation. Modify miscellaneous= code to use the MII registers instead of the internal registers where it= makes a difference. Relocate the internal phy to phy_address=3D1, and add= find_mii() to locate the address of the external mii phy. Prevent the= 'nasty random phy-reset' code from operating when an external phy is being= used. The probe code determines the previously used internal or external phy to= determine the initial mode it will use. Again, our implementation does= not have an EEPROM, so we rely on the mode that our boot rom used to setup= the Ethernet. Gary oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 --=====_108637892911942=_ Content-Type: text/html; charset="us-ascii"

Jeff,

This is the third of a series of patches needed to support our product using the DP83815.

This patch permits operation of an external PHY.  Updates the mdio_read and mdio_write functions to permit actual MII operation.  Modify miscellaneous code to use the MII registers instead of the internal registers where it makes a difference.  Relocate the internal phy to phy_address=1, and add find_mii() to locate the address of the external mii phy.  Prevent the 'nasty random phy-reset' code from operating when an external phy is being used.

The probe code determines the previously used internal or external phy to determine the initial mode it will use.  Again, our implementation does not have an EEPROM, so we rely on the mode that our boot rom used to setup the Ethernet.

Gary

 
 oooooooooooooooooooooooooooooooooooooooooooooooooo
 Gary Spiess (Gary.Spiess@Intermec.com)
 MobileLan Wireless Products Group, Intermec Technology Corp
 voice: 319 369-3580  fax: 319 369-3804
--=====_108637892911942=_-- --=====_10863789292995=_ Content-Type: application/octet-stream; name="natsemi-2.6.6-3.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="natsemi-2.6.6-3.patch" LS0tIGxpbnV4LTIuNi42L2RyaXZlcnMvbmV0L25hdHNlbWkuYwkyMDA0LTA2 LTAzIDE1OjQ0OjM0LjAwMDAwMDAwMCAtMDUwMAorKysgbGludXgvZHJpdmVy cy9uZXQvbmF0c2VtaS5jCTIwMDQtMDYtMDMgMTU6NDQ6NDcuMDAwMDAwMDAw IC0wNTAwCkBAIC00NjgsNiArNDY4LDkgQEAKIAlFRV9EYXRhSW4JCT0gMHgw MSwKIAlFRV9DaGlwU2VsZWN0CQk9IDB4MDgsCiAJRUVfRGF0YU91dAkJPSAw eDAyLAorCU1JSV9EYXRhIAkJPSAweDEwLAorCU1JSV9Xcml0ZQkJPSAweDIw LAorCU1JSV9TaGlmdENsawkJPSAweDQwLAogfTsKIAogZW51bSBQQ0lCdXND ZmdfYml0cyB7CkBAIC02MDIsNiArNjA1LDkgQEAKIAlQaHlBZGRyTWFzawkJ PSAweDFmLAogfTsKIAorLyogSW50ZXJuYWwgUGh5IGFkZHJlc3MgaXMgZml4 ZWQgKi8KKyNkZWZpbmUgUEhZX0FERFJfSU5URVJOQUwJMHgwMQorCiAvKiB2 YWx1ZXMgd2UgbWlnaHQgZmluZCBpbiB0aGUgc2lsaWNvbiByZXZpc2lvbiBy ZWdpc3RlciAqLwogI2RlZmluZSBTUlJfRFA4MzgxNV9DCTB4MDMwMgogI2Rl ZmluZSBTUlJfRFA4MzgxNV9ECTB4MDQwMwpAQCAtNjg1LDYgKzY5MSw3IEBA CiBzdGF0aWMgaW50IGVlcHJvbV9yZWFkKGxvbmcgaW9hZGRyLCBpbnQgbG9j YXRpb24pOwogc3RhdGljIGludCBtZGlvX3JlYWQoc3RydWN0IG5ldF9kZXZp Y2UgKmRldiwgaW50IHBoeV9pZCwgaW50IHJlZyk7CiBzdGF0aWMgdm9pZCBt ZGlvX3dyaXRlKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfaWQs IGludCByZWcsIHUxNiBkYXRhKTsKK3N0YXRpYyBpbnQgZmluZF9taWkoc3Ry dWN0IG5ldF9kZXZpY2UgKmRldik7CiBzdGF0aWMgdm9pZCBuYXRzZW1pX3Jl c2V0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOwogc3RhdGljIHZvaWQgbmF0 c2VtaV9yZWxvYWRfZWVwcm9tKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOwog c3RhdGljIHZvaWQgbmF0c2VtaV9zdG9wX3J4dHgoc3RydWN0IG5ldF9kZXZp Y2UgKmRldik7CkBAIC04MTIsMTAgKzgxOSwxNyBAQAogCW5wLT5tc2dfZW5h YmxlID0gKGRlYnVnID49IDApID8gKDE8PGRlYnVnKS0xIDogTkFUU0VNSV9E RUZfTVNHOwogCW5wLT5oYW5kc19vZmYgPSAwOwogCisJLyogZGVmYXVsdCB0 byBleHRlcm5hbCBwaHksIGlmIHByZXZpb3VzbHkgc2VsZWN0ZWQgKi8KKwlp ZiAocmVhZGwoZGV2LT5iYXNlX2FkZHIgKyBDaGlwQ29uZmlnKSAmIENmZ0V4 dFBoeSkKKwkJZGV2LT5pZl9wb3J0ID0gUE9SVF9NSUk7CisJZWxzZQorCQlk ZXYtPmlmX3BvcnQgPSBQT1JUX1RQOworCiAJLyogUmVzZXQgdGhlIGNoaXAg dG8gZXJhc2UgcHJldmlvdXMgbWlzY29uZmlndXJhdGlvbi4gKi8KIAluYXRz ZW1pX3JlbG9hZF9lZXByb20oZGV2KTsKIAluYXRzZW1pX3Jlc2V0KGRldik7 CiAKKwlucC0+cGh5X2FkZHJfZXh0ZXJuYWwgPSBmaW5kX21paShkZXYpOwog CW9wdGlvbiA9IGZpbmRfY250IDwgTUFYX1VOSVRTID8gb3B0aW9uc1tmaW5k X2NudF0gOiAwOwogCWlmIChkZXYtPm1lbV9zdGFydCkKIAkJb3B0aW9uID0g ZGV2LT5tZW1fc3RhcnQ7CkBAIC04NjAsMTYgKzg3NCwyMiBAQAogCX0KIAog CW5wLT5hZHZlcnRpc2luZyA9IG1kaW9fcmVhZChkZXYsIDEsIE1JSV9BRFZF UlRJU0UpOwotCWlmICgocmVhZGwoaW9hZGRyICsgQ2hpcENvbmZpZykgJiAw eGUwMDApICE9IDB4ZTAwMAorCWlmICgobnAtPmFkdmVydGlzaW5nICYgKEFE VkVSVElTRV8xMDBGVUxMfEFEVkVSVElTRV8xMEZVTEx8CisJCQkJQURWRVJU SVNFXzEwMEhBTEZ8QURWRVJUSVNFXzEwSEFMRikpICE9CisJCQkgICAgICAg KEFEVkVSVElTRV8xMDBGVUxMfEFEVkVSVElTRV8xMEZVTEx8CisJCQkJQURW RVJUSVNFXzEwMEhBTEZ8QURWRVJUSVNFXzEwSEFMRikKIAkgJiYgbmV0aWZf bXNnX3Byb2JlKG5wKSkgewotCQl1MzIgY2hpcF9jb25maWcgPSByZWFkbChp b2FkZHIgKyBDaGlwQ29uZmlnKTsKIAkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6 IFRyYW5zY2VpdmVyIGRlZmF1bHQgYXV0b25lZ290aWF0aW9uICVzICIKIAkJ CSIxMCVzICVzIGR1cGxleC5cbiIsCiAJCQlkZXYtPm5hbWUsCi0JCQljaGlw X2NvbmZpZyAmIENmZ0FuZWdFbmFibGUgPworCQkJKG1kaW9fcmVhZChkZXYs IDEsIE1JSV9CTUNSKSAmIEJNQ1JfQU5FTkFCTEUpPwogCQkJICAiZW5hYmxl ZCwgYWR2ZXJ0aXNlIiA6ICJkaXNhYmxlZCwgZm9yY2UiLAotCQkJY2hpcF9j b25maWcgJiBDZmdBbmVnMTAwID8gIjAiIDogIiIsCi0JCQljaGlwX2NvbmZp ZyAmIENmZ0FuZWdGdWxsID8gImZ1bGwiIDogImhhbGYiKTsKKwkJCShucC0+ YWR2ZXJ0aXNpbmcgJgorCQkJICAoQURWRVJUSVNFXzEwMEZVTEx8QURWRVJU SVNFXzEwMEhBTEYpKT8KKwkJCSAgICAiMCIgOiAiIiwKKwkJCShucC0+YWR2 ZXJ0aXNpbmcgJgorCQkJICAoQURWRVJUSVNFXzEwMEZVTEx8QURWRVJUSVNF XzEwRlVMTCkpPworCQkJICAgICJmdWxsIiA6ICJoYWxmIik7CiAJfQogCWlm IChuZXRpZl9tc2dfcHJvYmUobnApKQogCQlwcmludGsoS0VSTl9JTkZPCkBA IC05NTQsMjUgKzk3NCwxMDcgQEAKIAogLyogTUlJIHRyYW5zY2VpdmVyIGNv bnRyb2wgc2VjdGlvbi4KICAqIFRoZSA4MzgxNSBzZXJpZXMgaGFzIGFuIGlu dGVybmFsIHRyYW5zY2VpdmVyLCBhbmQgd2UgcHJlc2VudCB0aGUKLSAqIG1h bmFnZW1lbnQgcmVnaXN0ZXJzIGFzIGlmIHRoZXkgd2VyZSBNSUkgY29ubmVj dGVkLiAqLworICogaW50ZXJuYWwgbWFuYWdlbWVudCByZWdpc3RlcnMgYXMg aWYgdGhleSB3ZXJlIE1JSSBjb25uZWN0ZWQuCisgKiBFeHRlcm5hbCBQaHkg cmVnaXN0ZXJzIGFyZSByZWZlcmVuY2VkIHRocm91Z2ggdGhlIE1JSSBpbnRl cmZhY2UuCisgKi8KKworc3RhdGljIGludCBtaWlfZ2V0Yml0IChzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQoreworCWludCBkYXRhOworCisJd3JpdGViKE1J SV9TaGlmdENsaywgZGV2LT5iYXNlX2FkZHIgKyBFRUN0cmwpOworCWRhdGEg PSByZWFkYihkZXYtPmJhc2VfYWRkciArIEVFQ3RybCk7CisJdWRlbGF5KDEp OworCXdyaXRlYigwLCBkZXYtPmJhc2VfYWRkciArIEVFQ3RybCk7CisJdWRl bGF5KDEpOworCXJldHVybiAoZGF0YSAmIE1JSV9EYXRhKT8gMSA6IDA7Cit9 CisKK3N0YXRpYyB2b2lkIG1paV9zZW5kX2JpdHMgKHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYsIHUzMiBkYXRhLCBpbnQgbGVuKQoreworCXUzMiBpOworCisJ Zm9yIChpID0gKDEgPDwgKGxlbi0xKSk7IGk7IGkgPj49IDEpCisJeworCQl1 MzIgbWRpb192YWwgPSBNSUlfV3JpdGUgfCAoKGRhdGEgJiBpKT8gTUlJX0Rh dGEgOiAwKTsKKwkJd3JpdGViKG1kaW9fdmFsLCBkZXYtPmJhc2VfYWRkciAr IEVFQ3RybCk7CisJCXVkZWxheSgxKTsKKwkJd3JpdGViKG1kaW9fdmFsIHwg TUlJX1NoaWZ0Q2xrLCBkZXYtPmJhc2VfYWRkciArIEVFQ3RybCk7CisJCXVk ZWxheSgxKTsKKwl9CisJd3JpdGViKDAsIGRldi0+YmFzZV9hZGRyICsgRUVD dHJsKTsKKwl1ZGVsYXkoMSk7Cit9CiAKIHN0YXRpYyBpbnQgbWRpb19yZWFk KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfaWQsIGludCByZWcp CiB7Ci0JaWYgKHBoeV9pZCA9PSAxICYmIHJlZyA8IDMyKQorCXN0cnVjdCBu ZXRkZXZfcHJpdmF0ZSAqbnAgPSBkZXYtPnByaXY7CisJdTMyIGNtZDsKKwlp bnQgaTsKKwl1MzIgcmV0dmFsID0gMDsKKworCS8qIFRoZSA4MzgxNSBzZXJp ZXMgaGFzIGFuIGludGVybmFsIHRyYW5zY2VpdmVyOyBoYW5kbGUgc2VwYXJh dGVseSAqLworCWlmIChkZXYtPmlmX3BvcnQgPT0gUE9SVF9UUCkKIAkJcmV0 dXJuIHJlYWRsKGRldi0+YmFzZV9hZGRyK0Jhc2ljQ29udHJvbCsocmVnPDwy KSkmMHhmZmZmOwotCWVsc2UKLQkJcmV0dXJuIDB4ZmZmZjsKKwlpZiAocGh5 X2lkID09IFBIWV9BRERSX0lOVEVSTkFMKQorCQlwaHlfaWQgPSBucC0+cGh5 X2FkZHJfZXh0ZXJuYWw7CisKKwkvKiBFbnN1cmUgc3luYyAqLworCW1paV9z ZW5kX2JpdHMgKGRldiwgMHhmZmZmZmZmZiwgMzIpOworCS8qIFNUKDIpLCBP UCgyKSwgQUREUig1KSwgUkVHIyg1KSwgVEEoMiksIERhdGEoMTYpIHRvdGFs IDMyIGJpdHMgKi8KKwkvKiBTVCxPUCA9IDAxMTAnYiBmb3IgcmVhZCBvcGVy YXRpb24gKi8KKwljbWQgPSAoMHgwNiA8PCAxMCkgfCAocGh5X2lkIDw8IDUp IHwgcmVnOworCW1paV9zZW5kX2JpdHMgKGRldiwgY21kLCAxNCk7CisJLyog VHVybmFyb3VuZCAqLworCWlmIChtaWlfZ2V0Yml0IChkZXYpKQorCQlyZXR1 cm4gMDsKKwkvKiBSZWFkIGRhdGEgKi8KKwlmb3IgKGkgPSAwOyBpIDwgMTY7 IGkrKykgeworCQlyZXR2YWwgPDw9IDE7CisJCXJldHZhbCB8PSBtaWlfZ2V0 Yml0IChkZXYpOworCX0KKwkvKiBFbmQgY3ljbGUgKi8KKwltaWlfZ2V0Yml0 IChkZXYpOworCXJldHVybiByZXR2YWw7CiB9CiAKIHN0YXRpYyB2b2lkIG1k aW9fd3JpdGUoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9pZCwg aW50IHJlZywgdTE2IGRhdGEpCiB7CiAJc3RydWN0IG5ldGRldl9wcml2YXRl ICpucCA9IGRldi0+cHJpdjsKLQlpZiAocGh5X2lkID09IDEgJiYgcmVnIDwg MzIpIHsKKwl1MzIgY21kOworCisJc3dpdGNoIChyZWcpIHsKKwkJY2FzZSBN SUlfQURWRVJUSVNFOiBucC0+YWR2ZXJ0aXNpbmcgPSBkYXRhOyBicmVhazsK Kwl9CisKKwkvKiBUaGUgODM4MTUgc2VyaWVzIGhhcyBhbiBpbnRlcm5hbCB0 cmFuc2NlaXZlcjsgaGFuZGxlIHNlcGFyYXRlbHkgKi8KKwlpZiAoZGV2LT5p Zl9wb3J0ID09IFBPUlRfVFApIHsKIAkJd3JpdGV3KGRhdGEsIGRldi0+YmFz ZV9hZGRyK0Jhc2ljQ29udHJvbCsocmVnPDwyKSk7Ci0JCXN3aXRjaCAocmVn KSB7Ci0JCQljYXNlIE1JSV9BRFZFUlRJU0U6IG5wLT5hZHZlcnRpc2luZyA9 IGRhdGE7IGJyZWFrOwotCQl9CisJCXJldHVybjsKIAl9CisJaWYgKHBoeV9p ZCA9PSBQSFlfQUREUl9JTlRFUk5BTCkKKwkJcGh5X2lkID0gbnAtPnBoeV9h ZGRyX2V4dGVybmFsOworCisJLyogRW5zdXJlIHN5bmMgKi8KKwltaWlfc2Vu ZF9iaXRzIChkZXYsIDB4ZmZmZmZmZmYsIDMyKTsKKwkvKiBTVCgyKSwgT1Ao MiksIEFERFIoNSksIFJFRyMoNSksIFRBKDIpLCBEYXRhKDE2KSB0b3RhbCAz MiBiaXRzICovCisJLyogU1QsT1AsQUFBQUEsUlJSUlIsVEEgPSAwMTAxeHh4 eHh4eHh4eDEwJ2IgPSAweDUwMDIgZm9yIHdyaXRlICovCisJY21kID0gKDB4 NTAwMiA8PCAxNikgfCAocGh5X2lkIDw8IDIzKSB8IChyZWcgPDwgMTgpIHwg ZGF0YTsKKwltaWlfc2VuZF9iaXRzIChkZXYsIGNtZCwgMzIpOworCS8qIEVu ZCBjeWNsZSAqLworCW1paV9nZXRiaXQgKGRldik7Cit9CisKK3N0YXRpYyBp bnQgZmluZF9taWkoc3RydWN0IG5ldF9kZXZpY2UgKmRldikKK3sKKwlpbnQg dG1wOworCWludCBpOworCWZvciAoaSA9IDB4MWY7IGk7IGktLSkgeworCQl0 bXAgPSBtZGlvX3JlYWQoZGV2LCBpLCBNSUlfQk1TUik7CisJCWlmICh0bXAg IT0gMHhmZmZmICYmIHRtcCAhPSAweDAwMDApCisJCQlyZXR1cm4gaTsKKwl9 CisJcmV0dXJuIFBIWV9BRERSX0lOVEVSTkFMOwogfQogCiAvKiBDRkcgYml0 cyBbMTM6MTZdIFsxODoyM10gKi8KQEAgLTEwMzIsNiArMTEzNCwxMSBAQAog CQkJZGV2LT5uYW1lLCBpKjUpOwogCX0KIAorCS8qIHJlc2V0IGludGVybmFs IHBoeSB0byBmaXhlZCBtaWkgYWRkcmVzcyAqLworCXdyaXRldyhQSFlfQURE Ul9JTlRFUk5BTCwgZGV2LT5iYXNlX2FkZHIgKyBQaHlDdHJsKTsKKwkvKiB0 dXJuIG9uIGV4dGVybmFsIHBoeSBpZiBpdCB3YXMgc2VsZWN0ZWQgKi8KKwlp ZiAoZGV2LT5pZl9wb3J0ICE9IFBPUlRfVFApCisJCWNmZyB8PSAoQ2ZnRXh0 UGh5IHwgQ2ZnUGh5RGlzKTsKIAkvKiByZXN0b3JlIENGRyAqLwogCWNmZyB8 PSByZWFkbChkZXYtPmJhc2VfYWRkciArIENoaXBDb25maWcpICYgfkNGR19S RVNFVF9TQVZFOwogCXdyaXRlbChjZmcsIGRldi0+YmFzZV9hZGRyICsgQ2hp cENvbmZpZyk7CkBAIC0xMjA0LDkgKzEzMTEsOSBAQAogCXN0cnVjdCBuZXRk ZXZfcHJpdmF0ZSAqbnAgPSBkZXYtPnByaXY7CiAJbG9uZyBpb2FkZHIgPSBk ZXYtPmJhc2VfYWRkcjsKIAlpbnQgZHVwbGV4OwotCWludCBjaGlwY2ZnID0g cmVhZGwoaW9hZGRyICsgQ2hpcENvbmZpZyk7CisJaW50IGJtc3IgPSBtZGlv X3JlYWQoZGV2LCAxLCBNSUlfQk1TUik7CiAKLQlpZiAoIShjaGlwY2ZnICYg Q2ZnTGluaykpIHsKKwlpZiAoIShibXNyICYgQk1TUl9MU1RBVFVTKSkgewog CQlpZiAobmV0aWZfY2Fycmllcl9vayhkZXYpKSB7CiAJCQlpZiAobmV0aWZf bXNnX2xpbmsobnApKQogCQkJCXByaW50ayhLRVJOX05PVElDRSAiJXM6IGxp bmsgZG93bi5cbiIsCkBAIC0xMjIzLDcgKzEzMzAsMTYgQEAKIAkJZG9fY2Fi bGVfbWFnaWMoZGV2KTsKIAl9CiAKLQlkdXBsZXggPSBucC0+ZnVsbF9kdXBs ZXggfHwgKGNoaXBjZmcgJiBDZmdGdWxsRHVwbGV4ID8gMSA6IDApOworCWR1 cGxleCA9IG5wLT5mdWxsX2R1cGxleDsKKwlpZiAoIWR1cGxleCkgeworCQlp ZiAoYm1zciAmIEJNU1JfQU5FR0NPTVBMRVRFKSB7CisJCQlpbnQgdG1wID0g bWlpX253YXlfcmVzdWx0KAorCQkJCW5wLT5hZHZlcnRpc2luZyAmIG1kaW9f cmVhZChkZXYsIDEsIE1JSV9MUEEpKTsKKwkJCWlmICh0bXAgPT0gTFBBXzEw MEZVTEwgfHwgdG1wID09IExQQV8xMEZVTEwpCisJCQkJZHVwbGV4ID0gMTsK KwkJfSBlbHNlIGlmIChtZGlvX3JlYWQoZGV2LCAxLCBNSUlfQk1DUikgJiBC TUNSX0ZVTExEUExYKQorCQkJZHVwbGV4ID0gMTsKKwl9CiAKIAkvKiBpZiBk dXBsZXggaXMgc2V0IHRoZW4gYml0IDI4IG11c3QgYmUgc2V0LCB0b28gKi8K IAlpZiAoZHVwbGV4IF4gISEobnAtPnJ4X2NvbmZpZyAmIFJ4QWNjZXB0VHgp KSB7CkBAIC0xMjc4LDYgKzEzOTQsMTMgQEAKIAl3cml0ZXcoMCwgaW9hZGRy ICsgUEdTRUwpOwogCW5wLT5kc3BjZmcgPSBEU1BDRkdfVkFMOwogCisJLyog aWYgZXh0ZXJuYWwgcGh5LCB0aGVuIERTUENGRyByZWdpc3RlciBpc24ndCBm dW5jdGlvbmFsLgorCSAgIEZpeCB0aGUgdmFsdWUgaGVyZSBzbyB0aGUgIm5h c3R5IHJhbmRvbSBwaHktcmVzZXQiIGNvZGUgZG9lc24ndAorCSAgIHRoaW5r IGl0IG5lZWRzIHRvIHJlaW5pdGlhbGl6ZSB0aGUgY2hpcC4KKwkgKi8KKwlp ZiAoZGV2LT5pZl9wb3J0ICE9IFBPUlRfVFApCisJCW5wLT5kc3BjZmcgPSAw OworCiAJLyogRW5hYmxlIFBIWSBTcGVjaWZpYyBldmVudCBiYXNlZCBpbnRl cnJ1cHRzLiAgTGluayBzdGF0ZSBjaGFuZ2UKIAkgICBhbmQgQXV0by1OZWdv dGlhdGlvbiBDb21wbGV0aW9uIGFyZSBhbW9uZyB0aGUgYWZmZWN0ZWQuCiAJ ICAgUmVhZCB0aGUgaW50ciBzdGF0dXMgdG8gY2xlYXIgaXQgKG5lZWRlZCBm b3Igd2FrZSBldmVudHMpLgo= --=====_10863789292995=_-- From vkondra@mail.ru Mon Jun 7 06:28:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 06:29:07 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57DShgi012430 for ; Mon, 7 Jun 2004 06:28:44 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 4E2AEE5D8F for ; Sun, 6 Jun 2004 22:29:48 +0400 (MSD) Received: from [212.179.218.36] (port=38008 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BX2Nw-0005v6-00 for netdev@oss.sgi.com; Sun, 06 Jun 2004 22:28:46 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: in-driver QoS Date: Sun, 6 Jun 2004 21:28:47 +0300 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: <200406062128.47070.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5687 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: 1116 Lines: 28 I'd like to discuss issue with QoS. In 802.11 network, there is TGe (or 802.11e), working group, developing QoS extensions for 802.11. This group's work is close to finish. Current draft should be very close to the final standard. Currently, according to TGe, NIC will support 4 different priorities (or access categories). Let's say, 4 distinct Tx queues will be supported by NIC. Each Tx queue have its own parameters. In addition, there are separate streams (TSPEC's) that should be requested, i.e. before use, some initiation procedure should be performed. Sure, there is tear down for TSPEC as well. Roughly, 4 access categories corresponds to diffserv, while TSPEC's - to intserv. Now, question is: how will we support these QoS features in network stack? Let's start from diffserv, it is easier. skb->priority help determining Tx queue, but fundamental problem is with single Tx queue from network stack. Any smart queuing/scheduling etc. made by driver, will render useless while network stack provides single Tx queue. Any ideas how to modify stack to support multiple Tx queues? Vladimir From dave@thedillows.org Mon Jun 7 06:52:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 06:52:38 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57DqSgi013811 for ; Mon, 7 Jun 2004 06:52:29 -0700 Received: (qmail 30655 invoked from network); 7 Jun 2004 13:52:27 -0000 Received: from unknown (HELO ori.thedillows.org) (69.1.45.93) by smtp6.knology.net with SMTP; 7 Jun 2004 13:52:27 -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 i57DqR51019484; Mon, 7 Jun 2004 09:52:27 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i57DqRP6019482; Mon, 7 Jun 2004 09:52:27 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: [0/3] mc_filter on big-endian arch From: David Dillow To: Roger Luethi Cc: Jeff Garzik , Andrew Morton , Netdev In-Reply-To: <20040607114832.GA32569@k3.hellgate.ch> References: <20040606165322.GA13247@k3.hellgate.ch> <1086575392.4731.9.camel@ori.thedillows.org> <20040607114832.GA32569@k3.hellgate.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1086616346.4903.12.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 07 Jun 2004 09:52:26 -0400 X-archive-position: 5688 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: 1010 Lines: 21 On Mon, 2004-06-07 at 07:48, Roger Luethi wrote: > On Sun, 06 Jun 2004 22:29:52 -0400, David Dillow wrote: > > I think typhoon's OK -- I calculate the filter on the host, and then do > > a cpu_to_le32() on the final values, since the processor on the NIC is > > in little-endian mode. > > > > However, I've never tested it. I'll be happy to do so, if someone will > > point me to appropriate code -- I've got an Ultra5 as well, so I can > > test both big and little endian machines. Otherwise, I'll test it when I > > get around to writing something, or someone reports a bug. :) > > Warning: This is a very basic functionality test using standard Linux > tools. Some existing multicast problems are detected by this (if you > screw up the endianness of the filter hash, you will know :-)). Others > are not. Thanks for the info; it seems typhoon may have some problems -- I see the 224.1.1.1 packets before I join the group, so I'll need to see what's up. I'll check big endian tonight, if possible. Dave From ak@suse.de Mon Jun 7 07:45:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 07:45:27 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57EjDgi016595 for ; Mon, 7 Jun 2004 07:45: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 40D6E6A8B60; Mon, 7 Jun 2004 16:00:12 +0200 (CEST) Date: Mon, 7 Jun 2004 16:00:11 +0200 From: Andi Kleen To: Vladimir Kondratiev Cc: netdev@oss.sgi.com Subject: Re: in-driver QoS Message-ID: <20040607140011.GC28639@wotan.suse.de> References: <200406062128.47070.vkondra@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406062128.47070.vkondra@mail.ru> X-archive-position: 5690 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: 733 Lines: 18 > Any ideas how to modify stack to support multiple Tx queues? It already has that kind of in the form of arbitary qdiscs. The trick will be only to do all queueing in the qdisc and keep the hardware queue length as small as possible. I think today's drivers can do that already by just plugging the queue most of the time, unless they really want a packet. Disadvantage will be more use of CPU time to refill driver queues, but at the relatively slow WLAN speeds that shouldn't be a big issue. BTW the standard qdisc pfifo_fast already has three queues, selected by the old TOS. That may even be good enough for you already. Users can fine tune it by using firewall rules that change the TOS for specific protocols etc. -Andi From joe@perches.com Mon Jun 7 07:48:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 07:48:56 -0700 (PDT) Received: from Perches.com (DSL022.labridge.com [206.117.136.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Emqgi016978 for ; Mon, 7 Jun 2004 07:48:52 -0700 Received: from [192.168.1.128] (local128.perches.com [192.168.1.128]) by Perches.com (8.9.3/8.9.3) with ESMTP id HAA07905; Mon, 7 Jun 2004 07:37:52 -0700 Subject: Re: [PATCH] common code for generating tcp_info From: Joe Perches To: Stephen Hemminger Cc: David S Miller , netdev@oss.sgi.com In-Reply-To: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> References: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> Content-Type: text/plain Message-Id: <1086619698.4113.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 07:48:18 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5691 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: 858 Lines: 21 On Fri, 2004-06-04 at 15:37, Stephen Hemminger wrote: > diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c > --- a/net/ipv4/tcp_diag.c 2004-06-04 15:35:55 -07:00 > +++ b/net/ipv4/tcp_diag.c 2004-06-04 15:35:55 -07:00 > +void tcp_get_info(struct sock *sk, struct tcp_info *info) What is the appropriate text to update tcp.h? /* The syn_wait_lock is necessary only to avoid tcp_get_info having * to grab the main lock sock while browsing the listening hash * (otherwise it's deadlock prone). * This lock is acquired in read mode only from tcp_get_info() and * it's acquired in write mode _only_ from code that is actively * changing the syn_wait_queue. All readers that are holding * the master sock lock don't need to grab this lock in read mode * too as the syn_wait_queue writes are always protected from * the main sock lock. */ From Robert.Olsson@data.slu.se Mon Jun 7 07:57:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 07:57:37 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57EvYgi017860 for ; Mon, 7 Jun 2004 07:57:35 -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 i57EvUNY001193; Mon, 7 Jun 2004 16:57:30 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 8A2C3905BE; Mon, 7 Jun 2004 16:57:30 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16580.33370.535347.85788@robur.slu.se> Date: Mon, 7 Jun 2004 16:57:30 +0200 To: tharbaugh@lnxi.com Cc: netdev@oss.sgi.com Subject: abysmal e1000 performance (DITR) In-Reply-To: <1085700138.30156.1322.camel@tubarao> References: <1085700138.30156.1322.camel@tubarao> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 5692 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: 730 Lines: 21 Thayne Harbaugh writes: > This is a patch to include system load when calculating the DITR. It > only allows the diff/goc ratio to factor into the DITR when the 1 minute > load average is above .50. It appears to work quite well and prevents > throttling when the load is below .50 and allows throttling when the > load is in excess of .50. Hello! The experience we had from decorrelating network traffic for use with variable interrupt delays etc was that no average based scheme worked at the packet resolution we wanted. The only useful measure we found was using the number of packets received on the RX-ring. You see this used in tulip driver to get a dynamic RX interrupt delay. Cheers. --ro From shemminger@osdl.org Mon Jun 7 09:16:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 09:16:56 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57GGqgi023398 for ; Mon, 7 Jun 2004 09:16:53 -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 i57GG8r05800; Mon, 7 Jun 2004 09:16:08 -0700 Date: Mon, 7 Jun 2004 09:16:08 -0700 From: Stephen Hemminger To: Joe Perches , David S Miller Cc: netdev@oss.sgi.com Subject: Re: [PATCH] common code for generating tcp_info Message-Id: <20040607091608.07924826@dell_ss3.pdx.osdl.net> In-Reply-To: <1086619698.4113.22.camel@localhost.localdomain> References: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> <1086619698.4113.22.camel@localhost.localdomain> 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: 5693 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: 1047 Lines: 20 The comment was out of date, keep moving, nothing to see here... diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2004-06-07 09:15:59 -07:00 +++ b/include/linux/tcp.h 2004-06-07 09:15:59 -07:00 @@ -351,11 +351,11 @@ __u8 urg_mode; /* In urgent mode */ __u32 snd_up; /* Urgent pointer */ - /* The syn_wait_lock is necessary only to avoid tcp_get_info having + /* The syn_wait_lock is necessary only to avoid proc interface having * to grab the main lock sock while browsing the listening hash * (otherwise it's deadlock prone). - * This lock is acquired in read mode only from tcp_get_info() and - * it's acquired in write mode _only_ from code that is actively + * This lock is acquired in read mode only from listening_get_next() + * and it's acquired in write mode _only_ from code that is actively * changing the syn_wait_queue. All readers that are holding * the master sock lock don't need to grab this lock in read mode * too as the syn_wait_queue writes are always protected from From n.srinivasan@vsnl.net Mon Jun 7 09:21:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 09:21:05 -0700 (PDT) Received: from smtp3.vsnl.net (smtp3.vsnl.net [203.200.235.233]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57GL1gi023769 for ; Mon, 7 Jun 2004 09:21:02 -0700 Received: from vsnl.net ([127.0.0.1]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HYY00E5D5FAET@smtp3.vsnl.net> for netdev@oss.sgi.com; Mon, 07 Jun 2004 21:51:10 +0530 (IST) Received: from ([172.16.28.137]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Mon, 07 Jun 2004 21:51:10 +0530 (IST) Received: from [172.16.28.183] by pop3.vsnl.net (mshttpd); Mon, 07 Jun 2004 21:20:56 +0500 Date: Mon, 07 Jun 2004 21:20:56 +0500 From: n.srinivasan@vsnl.net Subject: Regarding Concurrent accept() in Linux To: netdev@oss.sgi.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-archive-position: 5694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: n.srinivasan@vsnl.net Precedence: bulk X-list: netdev Content-Length: 486 Lines: 9 Hi, I read on the net that Linux supports concurrent accept(). Does this mean that two threads can call accept() on the same socket and dequeue a connection almost in parallel? Having looked at the code (2.6.6), I guess tcp_accept() routine grabs a lock before dequeueing the eager connection. I guess this is the point it gets serialised. If this is the case, there isnt much difference from the BSD code. Or is concurrent accept() a different feature altogether. Cheers, Cheenu. From hadi@cyberus.ca Mon Jun 7 09:29:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 09:29:45 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57GTagi024169 for ; Mon, 7 Jun 2004 09:29:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BXI9B-0008IP-8k for netdev@oss.sgi.com; Mon, 07 Jun 2004 07:18:33 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BXI97-0007yF-DG; Mon, 07 Jun 2004 07:18:29 -0400 Subject: Re: [Bonding-devel] Re: [PATCH 2.6] e100: use NAPI mode all the time From: jamal Reply-To: hadi@cyberus.ca To: Jay Vosburgh Cc: Jeff Garzik , Tim Mattox , sfeldma@pobox.com, netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, Scott Feldman In-Reply-To: <200406070639.i576drvF026556@death.nxdomain.ibm.com> References: <200406070639.i576drvF026556@death.nxdomain.ibm.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086607077.1590.267.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jun 2004 07:17:58 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5695 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: 356 Lines: 13 Hi, dont have time to go through all that thread, but lets understand your problem and setup. Lets start with the setup: You have 4 ethx ports on PC1 x-connected to 4 on PC2. You have bonding on PC1 but not on PC2. You have NAPI on both PC1 and PC2. Is any of them multiprocessor? Lets get the setup then we can continue the discussion. cheers, jamal From shemminger@osdl.org Mon Jun 7 10:07:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 10:07:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57H7vgi025655 for ; Mon, 7 Jun 2004 10:07:57 -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 i57H7ir26225; Mon, 7 Jun 2004 10:07:44 -0700 Date: Mon, 7 Jun 2004 10:07:44 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] add receive DRS info Message-Id: <20040607100744.1b67baa2@dell_ss3.pdx.osdl.net> In-Reply-To: <20040604205749.11725598.davem@redhat.com> References: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> <20040604205749.11725598.davem@redhat.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: 5697 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: 1085 Lines: 32 Add receiver feedback information to the tcp_info structure to allow looking at receive dynamic right sizing with 'ss' command. This increases the size of the structure, but since both getsockopt() and netlink interface pass length in request; it retains compatibility with older versions. diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2004-06-07 10:07:25 -07:00 +++ b/include/linux/tcp.h 2004-06-07 10:07:25 -07:00 @@ -183,6 +183,9 @@ __u32 tcpi_snd_cwnd; __u32 tcpi_advmss; __u32 tcpi_reordering; + + __u32 tcpi_rcv_rtt; + __u32 tcpi_rcv_space; }; #ifdef __KERNEL__ diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c 2004-06-07 10:07:25 -07:00 +++ b/net/ipv4/tcp_diag.c 2004-06-07 10:07:25 -07:00 @@ -91,6 +91,9 @@ 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_space = tp->rcvq_space.space; } static int tcpdiag_fill(struct sk_buff *skb, struct sock *sk, From Gary.Spiess@Intermec.com Mon Jun 7 11:05:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 11:05:34 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57I5Vgi027975 for ; Mon, 7 Jun 2004 11:05:31 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id MAA03532; Mon, 7 Jun 2004 12:58:56 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i5814EKJ032607; Mon, 7 Jun 2004 20:04:15 -0500 Message-ID: <200406071258550931.1ACDCC8B@136.179.85.112> In-Reply-To: <40C31C71.6000101@colorfullife.com> References: <200406041451590078.0BC23855@136.179.85.112> <40C31C71.6000101@colorfullife.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Mon, 07 Jun 2004 12:58:55 -0500 From: "Gary N Spiess" To: manfred@colorfullife.com Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i57I5Vgi027975 X-archive-position: 5698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 4296 Lines: 135 Jeff, I agree with all comments. Regarding the total elimination of this patch ... Only our bootrom knows the MAC address that should be used, and it appends it to the bootargs. If there is a way for the userspace to take a peek at the bootargs (or a similar mechanism), we can use the ifconfig method to assign the MAC address instead of changing the driver. I'd prefer it. Gary *********** REPLY SEPARATOR *********** On 6/6/2004 at 3:30 PM Manfred Spraul wrote: >Gary N Spiess wrote: > >>Jeff, >>This is the first of a series of patches needed to support our product >using the DP83815. >>This patch accepts the MAC address as a parameter because our >implementation does not have an EEPROM. I tried to upgrade to the new >module_param_array() macro, but couldn't find a tutorial on the new param >scheme. >> >Ok. Appending "natsemi.ethaddr=00:01:02:04:05:06" works. > >> To get things working for our development, I use a __setup() wrapper to >get "ethaddr=" from the linux command line. >> >> >That's not a reason to merge a hack > >>+ if (find_cnt < ethaddr_num) >> >> >I think we should add a special case: if strlen(ethaddr[find_cnt]) is 0, >then the address from the eeprom is used - this allows to replace one >mac address if multiple nics are installed. > >>+ { >> >> >Coding style: the { should be in the same line as the if > >>+ int i, a[6]; >> >> >i already exists, no need to define another instance. > >I've appended an updated patch - could you test it? > >But: I'm not sure that the change is required. What about just setting >the mac to 0, and the actual mac address is set from user space? It's >possible to set the mac address with > ># ifconfig eth2 ether 80:01:02:03:04:05 > >Is there a reason why you cannot set the mac address from user space? > >-- > Manfred > > >--- 2.6/drivers/net/natsemi.c 2004-05-10 04:31:59.000000000 +0200 >+++ build-2.6/drivers/net/natsemi.c 2004-06-06 15:27:12.124436291 +0200 >@@ -147,6 +147,7 @@ > > #include > #include >+#include > #include > #include > #include >@@ -209,6 +210,8 @@ > #define MAX_UNITS 8 /* More are supported, limit only on options */ > static int options[MAX_UNITS]; > static int full_duplex[MAX_UNITS]; >+static char *ethaddr[MAX_UNITS] = {NULL, }; >+static int ethaddr_num = 0; > > /* Operational parameters that are set at compile time. */ > >@@ -256,6 +259,7 @@ > 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_param_array(ethaddr, charp, ethaddr_num, S_IRUGO); > MODULE_PARM_DESC(max_interrupt_work, > "DP8381x maximum events handled per interrupt"); > MODULE_PARM_DESC(mtu, "DP8381x MTU (all boards)"); >@@ -265,6 +269,7 @@ > MODULE_PARM_DESC(options, > "DP8381x: Bits 0-3: media type, bit 17: full duplex"); > MODULE_PARM_DESC(full_duplex, "DP8381x full duplex setting(s) (1)"); >+MODULE_PARM_DESC(ethaddr, "DP8381x MAC addr(s) xx:xx:xx:xx:xx:xx"); > > /* > Theory of Operation >@@ -776,13 +781,21 @@ > goto err_ioremap; > } > >- /* Work around the dropped serial bit. */ >- prev_eedata = eeprom_read(ioaddr, 6); >- for (i = 0; i < 3; i++) { >- int eedata = eeprom_read(ioaddr, i + 7); >- dev->dev_addr[i*2] = (eedata << 1) + (prev_eedata >> 15); >- dev->dev_addr[i*2+1] = eedata >> 7; >- prev_eedata = eedata; >+ if (find_cnt < ethaddr_num && strlen(ethaddr[find_cnt]) > 0) { >+ int a[6]; >+ sscanf(ethaddr[find_cnt], "%2x:%2x:%2x:%2x:%2x:%2x", >+ &a[0], &a[1], &a[2], &a[3], &a[4], &a[5]); >+ for (i = 6; i--; ) >+ dev->dev_addr[i] = (unsigned char)a[i]; >+ } else { >+ /* Work around the dropped serial bit. */ >+ prev_eedata = eeprom_read(ioaddr, 6); >+ for (i = 0; i < 3; i++) { >+ int eedata = eeprom_read(ioaddr, i + 7); >+ dev->dev_addr[i*2] = (eedata << 1) + (prev_eedata >> 15); >+ dev->dev_addr[i*2+1] = eedata >> 7; >+ prev_eedata = eedata; >+ } > } > > dev->base_addr = ioaddr; oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 From tharbaugh@lnxi.com Mon Jun 7 11:11:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 11:11:27 -0700 (PDT) Received: from ash.lnxi.com (208.177.141.226.ptr.us.xo.net [208.177.141.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57IBNgi028362 for ; Mon, 7 Jun 2004 11:11:23 -0700 Received: (qmail 19308 invoked from network); 7 Jun 2004 18:12:20 -0000 Received: from tubarao.lnxi.com (HELO ?192.168.15.106?) (192.168.15.106) by ash.lnxi.com with SMTP; 7 Jun 2004 18:12:20 -0000 Subject: Re: abysmal e1000 performance (DITR) From: Thayne Harbaugh Reply-To: tharbaugh@lnxi.com To: Robert Olsson Cc: netdev@oss.sgi.com In-Reply-To: <16580.33370.535347.85788@robur.slu.se> References: <1085700138.30156.1322.camel@tubarao> <16580.33370.535347.85788@robur.slu.se> Content-Type: text/plain Organization: Linux Networx Message-Id: <1086631191.5220.15.camel@tubarao> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 07 Jun 2004 11:59:52 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 5699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tharbaugh@lnxi.com Precedence: bulk X-list: netdev Content-Length: 1931 Lines: 46 On Mon, 2004-06-07 at 08:57, Robert Olsson wrote: > Thayne Harbaugh writes: > > > This is a patch to include system load when calculating > > the DITR. It only allows the diff/goc ratio to factor > > into the DITR when the 1 minute load average is above .50. > > It appears to work quite well and prevents throttling > > when the load is below .50 and allows throttling when the > > load is in excess of .50. > > Hello! > > The experience we had from decorrelating network traffic for use with > variable interrupt delays etc was that no average based scheme worked > at the packet resolution we wanted. That is absolutely a problem. The instantaneous load isn't available. Because one minute resolution is the lowest granularity then there is some delay between heavy load and the interrupts being reduced. This could be improved by using the derivative of the one-minute load average, but then the formula starts getting messy and difficult to follow. For now, the delay is acceptable with respect to having the DITR influenced by the load. > The only useful measure we found was using the number of packets > received on the RX-ring. You see this used in tulip driver to get a > dynamic RX interrupt delay. That, however, is exactly the problem. When only the packets are considered then interrupts are throttled even when the system can handle the extra load of heavy interrupts. When the interrupts are unnecessarily throttled without considering the system load then network throughput is greatly reduced - even though the system is mostly idle. That approach is too naive for balanced performance between network throughput and application processing. In the end, I thing that DITR should be disabled in favor of NAPI which has a similar goal and is more general. FWIW, I haven't looked through the tulip driver. Thanks for the pointer - I'll go have a peek. -- Thayne Harbaugh Linux Networx From shemminger@osdl.org Mon Jun 7 11:16:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 11:16:55 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57IGqgi028739 for ; Mon, 7 Jun 2004 11:16: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 i57IGdr06223; Mon, 7 Jun 2004 11:16:39 -0700 Date: Mon, 7 Jun 2004 11:16:38 -0700 From: Stephen Hemminger To: "Gary N Spiess" Cc: manfred@colorfullife.com, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Message-Id: <20040607111638.663de0a6@dell_ss3.pdx.osdl.net> In-Reply-To: <200406071258550931.1ACDCC8B@136.179.85.112> References: <200406041451590078.0BC23855@136.179.85.112> <40C31C71.6000101@colorfullife.com> <200406071258550931.1ACDCC8B@136.179.85.112> 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: 5700 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: 493 Lines: 10 On Mon, 07 Jun 2004 12:58:55 -0500 "Gary N Spiess" wrote: > Jeff, > > I agree with all comments. Regarding the total elimination of this patch ... > > Only our bootrom knows the MAC address that should be used, and it appends it to the bootargs. If there is a way for the userspace to take a peek at the bootargs (or a similar mechanism), we can use the ifconfig method to assign the MAC address instead of changing the driver. I'd prefer it. /proc/cmdline?? From scott.feldman@intel.com Mon Jun 7 11:33:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 11:33:26 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57IXNgi030186 for ; Mon, 7 Jun 2004 11:33:23 -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 i57IWojc009545 for ; Mon, 7 Jun 2004 18:32: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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i57IYDgS007803 for ; Mon, 7 Jun 2004 18:34:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060711331331684 for ; Mon, 07 Jun 2004 11:33:13 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 11:33:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [RFC] Wireless extensions rethink Date: Mon, 7 Jun 2004 11:33:10 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] Wireless extensions rethink Thread-Index: AcRMvlMymK6yV2hQRSGPtC6IcKsRZQ== From: "Feldman, Scott" To: X-OriginalArrivalTime: 07 Jun 2004 18:33:13.0882 (UTC) FILETIME=[E4780FA0:01C44CBD] 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 i57IXNgi030186 X-archive-position: 5701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 1501 Lines: 47 Jeff suggested in an earlier post that there is an opportunity to totally rethink the wireless extensions now that we have wireless-2.6. Let's get rid of the iotcl and /proc interfaces as Jeff suggests: 1) iw_handler API goes away and is replaced by struct net_device::wireless_ops (ala ethtool_ops). 2) sysfs get/set mapping for wireless_ops. 3) iw_statistics just becomes one of the wireless_ops. 4) Remove /proc/net/wireless support from wireless.c. (Already have sysfs support for the same :) 5) No private handler support. If you need private support, pass it in some other way (custom sysfs of modparam). Or, better yet, make a case that others could benefit and move into wireless_ops as standard. 6) Convert drivers from iw_handler and iw_statistics to wireless_ops. 7) Rewrite iw* tools to use sysfs interface rather than ioctl. (scriptable tools?) 8) [Optional] Remove iotcl interface. May want to keep for backward compat with legacy tools? Easy to map between ioctl and wireless_ops in wireless.c. 9) [Open] What to do about wireless events? Any ideas? Proposed sysfs layout: class/ `-- net |-- eth[x] |-- wireless |-- statistics | |-- beacon | |-- crypt | `-- ... `-- control |-- commit |-- name |-- network_id |-- freq `-- ... Is someone already working on this??? Comments? -scott From shemminger@osdl.org Mon Jun 7 11:39:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 11:39:46 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Idfgi030544 for ; Mon, 7 Jun 2004 11:39: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 i57IdXr11153; Mon, 7 Jun 2004 11:39:33 -0700 Date: Mon, 7 Jun 2004 11:39:33 -0700 From: Stephen Hemminger To: "Feldman, Scott" Cc: Subject: Re: [RFC] Wireless extensions rethink Message-Id: <20040607113933.4eb42ab3@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: 5702 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: 1865 Lines: 49 On Mon, 7 Jun 2004 11:33:10 -0700 "Feldman, Scott" wrote: > Jeff suggested in an earlier post that there is an opportunity to > totally rethink the wireless extensions now that we have wireless-2.6. > > Let's get rid of the iotcl and /proc interfaces as Jeff suggests: > > 1) iw_handler API goes away and is replaced by struct > net_device::wireless_ops (ala ethtool_ops). > 2) sysfs get/set mapping for wireless_ops. > 3) iw_statistics just becomes one of the wireless_ops. > 4) Remove /proc/net/wireless support from wireless.c. (Already > have sysfs support for the same :) > 5) No private handler support. If you need private support, > pass it in some other way (custom sysfs of modparam). Or, > better yet, make a case that others could benefit and move > into wireless_ops as standard. > 6) Convert drivers from iw_handler and iw_statistics to > wireless_ops. > 7) Rewrite iw* tools to use sysfs interface rather than ioctl. > (scriptable tools?) > 8) [Optional] Remove iotcl interface. May want to keep for > backward compat with legacy tools? Easy to map between > ioctl and wireless_ops in wireless.c. > 9) [Open] What to do about wireless events? Any ideas? > > Proposed sysfs layout: > > class/ > `-- net > |-- eth[x] > |-- wireless > |-- statistics > | |-- beacon > | |-- crypt > | `-- ... > `-- control > |-- commit > |-- name > |-- network_id > |-- freq > `-- ... That layout would mean that wireless needs to be a separate object (allocation/structure/kobject). Not bad, just one more issue to deal with. Go ahead and view existing sysfs wireless stuff as a prototype since no tools are using it (that I know of) yet. From chriscarpinello@hotmail.com Mon Jun 7 12:08:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 12:08:48 -0700 (PDT) Received: from hotmail.com (bay1-f101.bay1.hotmail.com [65.54.245.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57J8jgi031276 for ; Mon, 7 Jun 2004 12:08:45 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Jun 2004 12:08:40 -0700 Received: from 209.182.184.2 by by1fd.bay1.hotmail.msn.com with HTTP; Mon, 07 Jun 2004 19:08:40 GMT X-Originating-IP: [209.182.184.2] X-Originating-Email: [chriscarpinello@hotmail.com] X-Sender: chriscarpinello@hotmail.com From: "Chris Carpinello" To: netdev@oss.sgi.com Subject: e1000 w/ NAPI + SMP = 99% CPU utilization Date: Mon, 07 Jun 2004 15:08:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jun 2004 19:08:40.0742 (UTC) FILETIME=[D82D2460:01C44CC2] X-archive-position: 5703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chriscarpinello@hotmail.com Precedence: bulk X-list: netdev Content-Length: 564 Lines: 14 With a stock 2.6.5 kernel, I'm building the e1000 driver as a module w/ NAPI turned on for an SMP host (Dell PowerEdge 1650 with 4 1Gb Intel NICs). ksoftirqd/0 is using 99% CPU utilization. However, when I recompile the kernel with NAPI turned off, ksoftirqd/0 behaves normally. Likewise, when I leave NAPI configured but turn off SMP support, ksoftirqd is fine. The system in question has 2x Intel Corp. 82544EI (rev 02) and 2x Intel Corp. 82543GC (rev 02). I'm willing to test patches. Please CC me on responses, as I'm not subscribed. Thanks. - Chris From Robert.Olsson@data.slu.se Mon Jun 7 12:14:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 12:14:38 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57JEUgi031670 for ; Mon, 7 Jun 2004 12:14:31 -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 i57JESNY032600; Mon, 7 Jun 2004 21:14:28 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 0804B905BE; Mon, 7 Jun 2004 21:14:28 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16580.48787.965298.891413@robur.slu.se> Date: Mon, 7 Jun 2004 21:14:27 +0200 To: tharbaugh@lnxi.com Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: abysmal e1000 performance (DITR) In-Reply-To: <1086631191.5220.15.camel@tubarao> References: <1085700138.30156.1322.camel@tubarao> <16580.33370.535347.85788@robur.slu.se> <1086631191.5220.15.camel@tubarao> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 5704 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: 1210 Lines: 29 Thayne Harbaugh writes: > > > The only useful measure we found was using the number of packets > > received on the RX-ring. You see this used in tulip driver to get a > > dynamic RX interrupt delay. > > That, however, is exactly the problem. When only the packets are > considered then interrupts are throttled even when the system can handle > the extra load of heavy interrupts. When the interrupts are > unnecessarily throttled without considering the system load then network > throughput is greatly reduced - even though the system is mostly idle. > That approach is too naive for balanced performance between network > throughput and application processing. > > In the end, I thing that DITR should be disabled in favor of NAPI which > has a similar goal and is more general. I'm not arguing with you. NAPI uses just number of received packets to decide which action to take and the decision gets instant and simple. > FWIW, I haven't looked through the tulip driver. Thanks for the pointer > - I'll go have a peek. Well it has a simple variant to avoid fixed interrupt delays and is used with NAPI in tulip. Jamal gave talk on this at OLS 2000?. Cheers. --ro From jgarzik@pobox.com Mon Jun 7 12:40:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 12:40: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.12.10/8.12.9) with SMTP id i57Je9gi003336 for ; Mon, 7 Jun 2004 12:40:10 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXPya-00077K-HN; Mon, 07 Jun 2004 20:40:08 +0100 Message-ID: <40C4C42F.2040006@pobox.com> Date: Mon, 07 Jun 2004 15:38:23 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: James Ketrenos , Netdev Subject: Re: Fwd: in-driver QoS References: <200406072217.31924.vkondra@mail.ru> In-Reply-To: <200406072217.31924.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5705 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: 501 Lines: 15 Vladimir Kondratiev wrote: > skb->priority help determining Tx queue, but fundamental problem is with > single Tx queue from network stack. Any smart queuing/scheduling etc. made by > driver, will render useless while network stack provides single Tx queue. The packet schedulers already have multiple queues, why isn't the packet scheduling framework sufficient? Who cares if there is a single TX "delivery point" to the driver, as long as the driver knows how to differentiate queues. Jeff From gwingerde@home.nl Mon Jun 7 13:29:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 13:29:56 -0700 (PDT) Received: from smtpq2.home.nl (smtpq2.home.nl [213.51.128.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57KTjgi004844 for ; Mon, 7 Jun 2004 13:29:46 -0700 Received: from [213.51.128.136] (port=51786 helo=smtp5.home.nl) by smtpq2.home.nl with esmtp (Exim 4.30) id 1BXQJA-00087P-LY; Mon, 07 Jun 2004 22:01:24 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([212.120.112.51]:37130 helo=[192.168.14.1]) by smtp5.home.nl with esmtp (Exim 4.30) id 1BXQJ8-0005NZ-F6; Mon, 07 Jun 2004 22:01:22 +0200 Message-ID: <40C4C741.5040708@home.nl> Date: Mon, 07 Jun 2004 21:51:29 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 0.6 (X11/20040526) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink Content-Type: multipart/mixed; boundary="------------030805080300000304000207" X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 5707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Content-Length: 12750 Lines: 459 This is a multi-part message in MIME format. --------------030805080300000304000207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Scott, I was thinking along the same lines, however I was taking the ethtool interface as the starting point (using a single ioctl for all wireless operations). The private handlers would just have to be converted to plain ioctls handled by the driver itself. The attached patch can be used as a starting point for this. It is not complete (not by far), but it shows the basic structure. I've called the structure wlantool_ops, again using the example set by ethtool. Comments? --- Gertjan. On Mon, 7 Jun 2004 11:33:10 -0700 "Feldman, Scott" wrote: > Jeff suggested in an earlier post that there is an opportunity to > totally rethink the wireless extensions now that we have wireless-2.6. > > Let's get rid of the iotcl and /proc interfaces as Jeff suggests: > > 1) iw_handler API goes away and is replaced by struct > net_device::wireless_ops (ala ethtool_ops). > 2) sysfs get/set mapping for wireless_ops. > 3) iw_statistics just becomes one of the wireless_ops. > 4) Remove /proc/net/wireless support from wireless.c. (Already > have sysfs support for the same :) > 5) No private handler support. If you need private support, > pass it in some other way (custom sysfs of modparam). Or, > better yet, make a case that others could benefit and move > into wireless_ops as standard. > 6) Convert drivers from iw_handler and iw_statistics to > wireless_ops. > 7) Rewrite iw* tools to use sysfs interface rather than ioctl. > (scriptable tools?) > 8) [Optional] Remove iotcl interface. May want to keep for > backward compat with legacy tools? Easy to map between > ioctl and wireless_ops in wireless.c. > 9) [Open] What to do about wireless events? Any ideas? > > Proposed sysfs layout: > > class/ > `-- net > |-- eth[x] > |-- wireless > |-- statistics > | |-- beacon > | |-- crypt > | `-- ... > `-- control > |-- commit > |-- name > |-- network_id > |-- freq > `-- ... > >Is someone already working on this??? > >Comments? > >-scott --------------030805080300000304000207 Content-Type: text/plain; name="wlantool.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="wlantool.diff" diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2004-06-07 21:29:13 +02:00 +++ b/include/linux/netdevice.h 2004-06-07 21:29:13 +02:00 @@ -41,6 +41,7 @@ struct divert_blk; struct vlan_group; struct ethtool_ops; +struct wlantool_ops; /* source back-compat hooks */ #define SET_ETHTOOL_OPS(netdev,ops) \ @@ -308,6 +309,8 @@ struct ethtool_ops *ethtool_ops; + struct wlantool_ops *wlantool_ops; + /* * This marks the end of the "visible" part of the structure. All * fields hereafter are internal to the system, and may change at @@ -678,6 +681,7 @@ extern int netif_receive_skb(struct sk_buff *skb); extern int dev_ioctl(unsigned int cmd, void __user *); extern int dev_ethtool(struct ifreq *); +extern int dev_wlantool(struct ifreq *); extern unsigned dev_get_flags(const struct net_device *); extern int dev_change_flags(struct net_device *, unsigned); extern int dev_set_mtu(struct net_device *, int); diff -Nru a/include/linux/sockios.h b/include/linux/sockios.h --- a/include/linux/sockios.h 2004-06-07 21:29:13 +02:00 +++ b/include/linux/sockios.h 2004-06-07 21:29:13 +02:00 @@ -83,6 +83,8 @@ #define SIOCWANDEV 0x894A /* get/set netdev parameters */ +#define SIOCWLANTOOL 0x894B /* WLANtool interface */ + /* ARP cache control calls. */ /* 0x8950 - 0x8952 * obsolete calls, don't re-use */ #define SIOCDARP 0x8953 /* delete ARP table entry */ diff -Nru a/include/linux/wlantool.h b/include/linux/wlantool.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/include/linux/wlantool.h 2004-06-07 21:29:13 +02:00 @@ -0,0 +1,72 @@ +/* + * wlantool.h: Defines for Linux WLANtool. + * + * Copyright (C) 2004 Gertjan van Wingerde (gwingerde@home.nl) + */ + +#ifndef _LINUX_WLANTOOL_H +#define _LINUX_WLANTOOL_H + +#include /* For IFNAMSIZ, etc. */ + +/* This should work for both 32 and 64 bit userland. */ +struct wlantool_name { + u32 cmd; + char name[IFNAMSIZ]; +}; + +struct wlantool_param { + u32 cmd; + s32 value; + u8 fixed; + u8 disabled; + u16 flags; +}; + +struct wlantool_freq { + u32 cmd; + s32 mantissa; + s16 exponent; + u8 index; + u8 reserved; +}; + +struct wlantool_mode { + u32 cmd; + u32 mode; +}; + +struct net_device; + +/** + * &wlantool_ops - Alter and report network device settings + * + * Description: + * + */ +struct wlantool_ops { + int (*commit)(struct net_device *); + void (*get_name)(struct net_device *, struct wlantool_name *); + int (*get_nwid)(struct net_device *, struct wlantool_param *); + int (*set_nwid)(struct net_device *, struct wlantool_param *); + int (*get_freq)(struct net_device *, struct wlantool_freq *); + int (*set_freq)(struct net_device *, struct wlantool_freq *); + int (*get_mode)(struct net_device *, struct wlantool_mode *); + int (*set_mode)(struct net_device *, struct wlantool_mode *); + int (*get_sens)(struct net_device *, struct wlantool_param *); + int (*set_sens)(struct net_device *, struct wlantool_param *); +}; + +/* CMDs currently supported */ +#define WLANTOOL_COMMIT 0x00000001 /* Commit pending changes. */ +#define WLANTOOL_GNAME 0x00000002 /* Get name (=wireless protocol). */ +#define WLANTOOL_GNWID 0x00000003 /* Get network ID (the cell). */ +#define WLANTOOL_SNWID 0x00000004 /* Set network ID (pre-802.11). */ +#define WLANTOOL_GFREQ 0x00000005 /* Get channel/frequency (Hz). */ +#define WLANTOOL_SFREQ 0x00000006 /* Set channel/frequency (Hz). */ +#define WLANTOOL_GMODE 0x00000007 /* Get operation mode. */ +#define WLANTOOL_SMODE 0x00000008 /* Set operation mode. */ +#define WLANTOOL_GSENS 0x00000009 /* Get sensitivity (dBm). */ +#define WLANTOOL_SSENS 0x0000000a /* Set sensitivity (dBm). */ + +#endif /* _LINUX_WLANTOOL_H */ diff -Nru a/net/core/Makefile b/net/core/Makefile --- a/net/core/Makefile 2004-06-07 21:29:13 +02:00 +++ b/net/core/Makefile 2004-06-07 21:29:13 +02:00 @@ -7,7 +7,8 @@ obj-$(CONFIG_SYSCTL) += sysctl_net_core.o obj-y += flow.o dev.o ethtool.o dev_mcast.o dst.o \ - neighbour.o rtnetlink.o utils.o link_watch.o filter.o + neighbour.o rtnetlink.o utils.o link_watch.o filter.o \ + wlantool.o obj-$(CONFIG_SYSFS) += net-sysfs.o obj-$(CONFIG_NETFILTER) += netfilter.o diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-06-07 21:29:13 +02:00 +++ b/net/core/dev.c 2004-06-07 21:29:13 +02:00 @@ -2700,6 +2700,20 @@ case SIOCSIFLINK: return -EINVAL; + case SIOCWLANTOOL: + dev_load(ifr.ifr_name); + rtnl_lock(); + ret = dev_wlantool(&ifr); + rtnl_unlock(); + if (!ret) { + if (colon) + *colon = ':'; + if (copy_to_user(arg, &ifr, + sizeof(struct ifreq))) + ret = -EFAULT; + } + return ret; + /* * Unknown or private ioctl. */ diff -Nru a/net/core/wlantool.c b/net/core/wlantool.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/core/wlantool.c 2004-06-07 21:29:13 +02:00 @@ -0,0 +1,221 @@ +/* + * net/core/wlantool.c - WLANtool ioctl handler + * Copyright (c) 2004 Gertjan van Wingerde + * + * This file is where we call all the wlantool_ops commands to get + * the information wlantool needs. We fall back to calling do_ioctl() + * for drivers which haven't been converted to wlantool_ops yet. + * + * It's GPL, stupid. + */ + +#include +#include +#include +#include +#include +#include + +/* Handlers for each wlantool command */ + +static int wlantool_commit(struct net_device *dev) +{ + int err; + + if (!dev->wlantool_ops->commit) + return -EOPNOTSUPP; + + err = dev->wlantool_ops->commit(dev); + if (err < 0) + return err; + + return 0; +} + +static int wlantool_get_name(struct net_device *dev, void __user *useraddr) +{ + struct wlantool_name name; + + if (!dev->wlantool_ops->get_name) + return -EOPNOTSUPP; + + dev->wlantool_ops->get_name(dev, &name); + + if (copy_to_user(useraddr, &name, sizeof(name))) + return -EFAULT; + + return 0; +} + +static int wlantool_get_nwid(struct net_device *dev, void __user *useraddr) +{ + struct wlantool_param param; + int err; + + if (!dev->wlantool_ops->get_nwid) + return -EOPNOTSUPP; + + err = dev->wlantool_ops->get_nwid(dev, ¶m); + + if (copy_to_user(useraddr, ¶m, sizeof(param))) + return -EFAULT; + + return 0; +} + +static int wlantool_set_nwid(struct net_device *dev, char __user *useraddr) +{ + struct wlantool_param param; + + if (!dev->wlantool_ops->set_nwid) + return -EOPNOTSUPP; + + if (copy_from_user(¶m, useraddr, sizeof(param))) + return -EFAULT; + + return dev->wlantool_ops->set_nwid(dev, ¶m); +} + +static int wlantool_get_freq(struct net_device *dev, void __user *useraddr) +{ + struct wlantool_freq freq; + int err; + + if (!dev->wlantool_ops->get_freq) + return -EOPNOTSUPP; + + err = dev->wlantool_ops->get_freq(dev, &freq); + + if (copy_to_user(useraddr, &freq, sizeof(freq))) + return -EFAULT; + + return 0; +} + +static int wlantool_set_freq(struct net_device *dev, char __user *useraddr) +{ + struct wlantool_freq freq; + + if (!dev->wlantool_ops->set_freq) + return -EOPNOTSUPP; + + if (copy_from_user(&freq, useraddr, sizeof(freq))) + return -EFAULT; + + return dev->wlantool_ops->set_freq(dev, &freq); +} + +static int wlantool_get_mode(struct net_device *dev, void __user *useraddr) +{ + struct wlantool_mode mode; + int err; + + if (!dev->wlantool_ops->get_mode) + return -EOPNOTSUPP; + + err = dev->wlantool_ops->get_mode(dev, &mode); + + if (copy_to_user(useraddr, &mode, sizeof(mode))) + return -EFAULT; + + return 0; +} + +static int wlantool_set_mode(struct net_device *dev, char __user *useraddr) +{ + struct wlantool_mode mode; + + if (!dev->wlantool_ops->set_mode) + return -EOPNOTSUPP; + + if (copy_from_user(&mode, useraddr, sizeof(mode))) + return -EFAULT; + + return dev->wlantool_ops->set_mode(dev, &mode); +} + +static int wlantool_get_sens(struct net_device *dev, void __user *useraddr) +{ + struct wlantool_param param; + int err; + + if (!dev->wlantool_ops->get_sens) + return -EOPNOTSUPP; + + err = dev->wlantool_ops->get_sens(dev, ¶m); + + if (copy_to_user(useraddr, ¶m, sizeof(param))) + return -EFAULT; + + return 0; +} + +static int wlantool_set_sens(struct net_device *dev, char __user *useraddr) +{ + struct wlantool_param param; + + if (!dev->wlantool_ops->set_sens) + return -EOPNOTSUPP; + + if (copy_from_user(¶m, useraddr, sizeof(param))) + return -EFAULT; + + return dev->wlantool_ops->set_sens(dev, ¶m); +} + +/* The main entry point in this file. Called from net/core/dev.c */ + +int dev_wlantool(struct ifreq *ifr) +{ + struct net_device *dev = __dev_get_by_name(ifr->ifr_name); + void __user *useraddr = (void __user *) ifr->ifr_data; + u32 wlancmd; + + /* + * XXX: This can be pushed down into the wlantool_* handlers that + * need it. Keep existing behaviour for the moment. + */ + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (!dev || !netif_device_present(dev)) + return -ENODEV; + + if (!dev->wlantool_ops) + goto ioctl; + + if (copy_from_user(&wlancmd, useraddr, sizeof (wlancmd))) + return -EFAULT; + + switch (wlancmd) { + case WLANTOOL_COMMIT: + return wlantool_commit(dev); + case WLANTOOL_GNAME: + return wlantool_get_name(dev, useraddr); + case WLANTOOL_GNWID: + return wlantool_get_nwid(dev, useraddr); + case WLANTOOL_SNWID: + return wlantool_set_nwid(dev, useraddr); + case WLANTOOL_GFREQ: + return wlantool_get_freq(dev, useraddr); + case WLANTOOL_SFREQ: + return wlantool_set_freq(dev, useraddr); + case WLANTOOL_GMODE: + return wlantool_get_mode(dev, useraddr); + case WLANTOOL_SMODE: + return wlantool_set_mode(dev, useraddr); + case WLANTOOL_GSENS: + return wlantool_get_sens(dev, useraddr); + case WLANTOOL_SSENS: + return wlantool_set_sens(dev, useraddr); + default: + return -EOPNOTSUPP; + } + + ioctl: + if (dev->do_ioctl) + return dev->do_ioctl(dev, ifr, SIOCWLANTOOL); + return -EOPNOTSUPP; +} + +EXPORT_SYMBOL(dev_wlantool); --------------030805080300000304000207-- From shemminger@osdl.org Mon Jun 7 13:31:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 13:31:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57KV8gi005028 for ; Mon, 7 Jun 2004 13:31:08 -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 i57KUvr32002; Mon, 7 Jun 2004 13:30:57 -0700 Date: Mon, 7 Jun 2004 13:30:56 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] unclamp tcp receive window if doing dynamic receive sizing Message-Id: <20040607133056.5ab9e72d@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: 5708 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: 2010 Lines: 60 When running tests over higher speed links, the new 2.6 Dynamic Receiver Sizing code doesn't increase the window large enough. The problem is that the window clamp restricts the allowed window to the socket receive buffer size (85k) Easiest fix is to not restrict window clamp if we want to dynamic receiver stuff. This is what web100 did. Thanks to John Heffner for finding this. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-06-07 12:45:49 -07:00 +++ b/net/ipv4/tcp_input.c 2004-06-07 12:45:49 -07:00 @@ -300,7 +300,6 @@ static void tcp_init_buffer_space(struct sock *sk) { struct tcp_opt *tp = tcp_sk(sk); - int maxwin; if (!(sk->sk_userlocks & SOCK_RCVBUF_LOCK)) tcp_fixup_rcvbuf(sk); @@ -309,22 +308,24 @@ tp->rcvq_space.space = tp->rcv_wnd; - maxwin = tcp_full_space(sk); + if (!sysctl_tcp_moderate_rcvbuf) { + int maxwin = tcp_full_space(sk); - if (tp->window_clamp >= maxwin) { - tp->window_clamp = maxwin; + if (tp->window_clamp >= maxwin) { + tp->window_clamp = maxwin; - if (sysctl_tcp_app_win && maxwin > 4 * tp->advmss) - tp->window_clamp = max(maxwin - - (maxwin >> sysctl_tcp_app_win), - 4 * tp->advmss); + if (sysctl_tcp_app_win && maxwin > 4 * tp->advmss) + tp->window_clamp = max(maxwin - + (maxwin >> sysctl_tcp_app_win), + 4 * tp->advmss); + } + + /* Force reservation of one segment. */ + if (sysctl_tcp_app_win && + tp->window_clamp > 2 * tp->advmss && + tp->window_clamp + tp->advmss > maxwin) + tp->window_clamp = max(2 * tp->advmss, maxwin - tp->advmss); } - - /* Force reservation of one segment. */ - if (sysctl_tcp_app_win && - tp->window_clamp > 2 * tp->advmss && - tp->window_clamp + tp->advmss > maxwin) - tp->window_clamp = max(2 * tp->advmss, maxwin - tp->advmss); tp->rcv_ssthresh = min(tp->rcv_ssthresh, tp->window_clamp); tp->snd_cwnd_stamp = tcp_time_stamp; From greearb@candelatech.com Mon Jun 7 13:52:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 13:52:47 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Kqigi006125 for ; Mon, 7 Jun 2004 13:52:44 -0700 Received: from candelatech.com (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 i57L0TSb021120; Mon, 7 Jun 2004 14:00:29 -0700 Message-ID: <40C4D595.4050801@candelatech.com> Date: Mon, 07 Jun 2004 13:52:37 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gertjan van Wingerde CC: "Feldman, Scott" , netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink References: <40C4C741.5040708@home.nl> In-Reply-To: <40C4C741.5040708@home.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5710 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: 723 Lines: 24 Gertjan van Wingerde wrote: > Hi Scott, > > I was thinking along the same lines, however I was taking the ethtool > interface as the starting point (using a single ioctl for all wireless > operations). The private handlers would just have to be converted to > plain ioctls handled by the driver itself. > > The attached patch can be used as a starting point for this. > It is not complete (not by far), but it shows the basic structure. > I've called the structure wlantool_ops, again using the example set by > ethtool. > > Comments? For what it's worth, I like the idea of using a single IOCTL similar to ethtool... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From vkondra@mail.ru Mon Jun 7 14:00:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:00:09 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Kxvgi006686 for ; Mon, 7 Jun 2004 13:59:58 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 5090E1175CF for ; Tue, 8 Jun 2004 00:30:07 +0400 (MSD) Received: from [212.179.218.36] (port=12617 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BXQjJ-000M6M-00; Tue, 08 Jun 2004 00:28:26 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: Fwd: in-driver QoS Date: Mon, 7 Jun 2004 23:28:23 +0300 User-Agent: KMail/1.6.2 Cc: Jeff Garzik , James Ketrenos References: <200406072217.31924.vkondra@mail.ru> <40C4C42F.2040006@pobox.com> In-Reply-To: <40C4C42F.2040006@pobox.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072328.23836.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5712 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: 1391 Lines: 36 Jeff, Point is, wireless will support QoS on link level. Ethernet have no QoS on link, thus one Tx queue was sufficient. For those QoS discipline, parameters are chosen by access point. Network stack don't know these parameters. BTW, how could driver tell to the stack what QoS should be employed? If stack do not provide exactly the same QoS as driver need, driver's one will not work. For generic 802.11 wireless stack, it should be framework for the driver to use 4 Tx queues for diff serv (separate start/stop...), and also some hooks for integrated service. Otherwise, like with current, simple 802.11 w/o TGe and other extensions, each driver will need to reinvent the wheel. I know very little about ATM, but it have QoS, both diff serv and int serv. May be it is worth to borrow from it? Vladimir. On Monday 07 June 2004 22:38, Jeff Garzik wrote: > Vladimir Kondratiev wrote: > > skb->priority help determining Tx queue, but fundamental problem is with > > single Tx queue from network stack. Any smart queuing/scheduling etc. > > made by driver, will render useless while network stack provides single > > Tx queue. > > The packet schedulers already have multiple queues, why isn't the packet > scheduling framework sufficient? > > Who cares if there is a single TX "delivery point" to the driver, as > long as the driver knows how to differentiate queues. > > Jeff From jgarzik@pobox.com Mon Jun 7 13:59:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 13:59:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Kxggi006598 for ; Mon, 7 Jun 2004 13:59:43 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXK3t-0006hq-2S; Mon, 07 Jun 2004 14:21:13 +0100 Message-ID: <40C46BBC.7000001@pobox.com> Date: Mon, 07 Jun 2004 09:21:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Rothwell CC: Andrew Morton , Linus , ppc64-dev , netdev@oss.sgi.com Subject: Re: [PATCH] PPC64 iSeries virtual ethernet proc files References: <20040607164312.258a9f99.sfr@canb.auug.org.au> In-Reply-To: <20040607164312.258a9f99.sfr@canb.auug.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5711 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: 470 Lines: 18 Stephen Rothwell wrote: > Hi Andrew, > > From: David Gibson > > This patch just adds back some of the iserires_veth proc files to provide > information to user space (particularly Kudzu) to allow the virtual > ethernets to be discovered. These files existed in a 2.4 version of this > driver that was shipped by some distros. kudzu can find this stuff with ethtool, without adding this code. This code isn't needed in 2.6.x. Jeff From vkondra@mail.ru Mon Jun 7 14:08:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:08:54 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57L8ggi007574 for ; Mon, 7 Jun 2004 14:08:42 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id C11E311530E for ; Tue, 8 Jun 2004 00:36:07 +0400 (MSD) Received: from [212.179.218.36] (port=12622 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BXQpk-000Biw-00; Tue, 08 Jun 2004 00:35:04 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: in-driver QoS Date: Mon, 7 Jun 2004 23:35:04 +0300 User-Agent: KMail/1.6.2 Cc: Andi Kleen References: <200406062128.47070.vkondra@mail.ru> <20040607140011.GC28639@wotan.suse.de> In-Reply-To: <20040607140011.GC28639@wotan.suse.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072335.04125.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5713 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: 1318 Lines: 30 How could I use these multiple qdiscs? If I use existing driver framework, I have hard_start_xmit, that represent single queue. Do you have any examples how driver can access qdiscs directly? I.e. I have 4 queues in the driver, I want to fill it separately, start/stop incoming queues from stack etc. Note also, we are talking about 100Mbps above MAC, which translates to about 150 Mbps, within next 2 years. 100Mbps above MAC is criteria for TGn working group in IEEE (high throughput). Vladimir. On Monday 07 June 2004 17:00, Andi Kleen wrote: > > Any ideas how to modify stack to support multiple Tx queues? > > It already has that kind of in the form of arbitary qdiscs. The trick > will be only to do all queueing in the qdisc and keep the hardware > queue length as small as possible. I think today's drivers can > do that already by just plugging the queue most of the time, > unless they really want a packet. > > Disadvantage will be more use of CPU time to refill driver > queues, but at the relatively slow WLAN speeds that shouldn't > be a big issue. > > BTW the standard qdisc pfifo_fast already has three queues, > selected by the old TOS. That may even be good enough for you > already. Users can fine tune it by using firewall rules > that change the TOS for specific protocols etc. > > -Andi From Gary.Spiess@Intermec.com Mon Jun 7 14:09:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:09:46 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57L9hgi007753 for ; Mon, 7 Jun 2004 14:09:44 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id QAA07117; Mon, 7 Jun 2004 16:08:46 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i584OaKJ000602; Mon, 7 Jun 2004 23:24:36 -0500 Message-ID: <200406071608450571.1B7B9754@136.179.85.112> In-Reply-To: <40C33D38.1060102@colorfullife.com> References: <200406041455290031.0BC56C76@136.179.85.112> <40C33D38.1060102@colorfullife.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Mon, 07 Jun 2004 16:08:45 -0500 From: "Gary N Spiess" To: manfred@colorfullife.com Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 3/4 External PHY operation 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 i57L9hgi007753 X-archive-position: 5714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 3612 Lines: 71 Manfred, > + if (phy_id == PHY_ADDR_INTERNAL) > + phy_id = np->phy_addr_external; - Your point is well taken. That *is* confusing, but what I meant to do. The existing driver code was already written to reference the "current PHY" with address 1. To select a different address to represent the current PHY would have required me to touch more lines of source. - My external and internal PHY hardware both default to address 31. When I want to reference the external PHY, I must change the internal address to something else. Because I already clobbered the meaning of address '1' to mean the 'current PHY' (as described above), I also used the number for the actual address of the internal PHY. I don't think there is a benefit to determining that '1' was not being used by an external PHY. - The short cable fix (to the best of my knowledge) is internal PHY related. The unmodified code didn't cause me problems when operating with an external PHY. - The partial reset fix (again, to the best of my knowledge) is only needed when the internal PHY being used has reset, but the MAC has not. The dspcfg != np->dspcfg test identifies an internal PHY that has been reset, and triggers the driver to do a a complete MAC/PHY reset. When using an external PHY, the test continually causes unneeded resets. The change to set np->dspcfg to 0 prevents it. This was the minimal change to get the desired results. - I have not been able to actually use the bit-banging MII interface to reference the internal PHY, regardless of which address it occupies. That's why I've chosen the internal PHY to be if_port = PORT_TP and external to be if_port = PORT_MII. You won't be able to use the internal PHY without also enabling the short cable and partial reset fixes. Gary *********** REPLY SEPARATOR *********** On 6/6/2004 at 5:50 PM Manfred Spraul wrote: >Gary N Spiess wrote: > >>Relocate the internal phy to phy_address=1, and add find_mii() to locate >the address of the external mii phy. >> >What if phy_address 1 is already in use? > >> } >> + if (phy_id == PHY_ADDR_INTERNAL) >> + phy_id = np->phy_addr_external; >> + > >Hmm. If the phy_id is internal then it's external. >What do you actually try to do? If I understand the hardware correctly, >it supports >- an internal PHY. Accessed through mapped registers. Used if >dev->if_port == PORT_TP. >- an external MII bus. Accessed by bit banging. Used if dev->if_port == >PORT_MII. >- most users of mdio_{read,write} want to access the currently selected >PHY, but they call mdio_read(,1,). The "if (phy_id ==INTERNAL) >phy_id=external" line is a hack to handle that. > >What about defining a PHY_ADDR_CUR (32, whatever). Everyone except the >probe code uses that value and mdio_read selects the correct port/phy >value from the dev structure. Or create a mdio_read_cur() function. > >> + /* if external phy, then DSPCFG register isn't functional. >> + Fix the value here so the "nasty random phy-reset" code >doesn't >> + think it needs to reinitialize the chip. >> + */ >> + if (dev->if_port != PORT_TP) >> + np->dspcfg = 0; >> + > >What about making the phy reset itself dependant on if->if_port? This >approach just asks for bugs - switch with ethtool from PORT_TP to >PORT_MII and suddenly short cables stop working. > >-- > Manfred oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 From Gary.Spiess@Intermec.com Mon Jun 7 14:14:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:14:03 -0700 (PDT) Received: from cesium.norand.com (cesium.norand.com [136.179.160.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57LE1gi017120 for ; Mon, 7 Jun 2004 14:14:01 -0700 Received: from spiess2.norand.com (IDENT:0@spiess2.norand.com [136.179.85.112]) by cesium.norand.com (8.9.3 (PHNE_28809+JAGae91741)/8.9.3) with ESMTP id QAA07197; Mon, 7 Jun 2004 16:12:49 -0500 (CDT) Received: from SPIESS (spiess.norand.com [136.179.85.111]) by spiess2.norand.com (8.12.10/8.12.10) with ESMTP id i584SrKJ000612; Mon, 7 Jun 2004 23:28:53 -0500 Message-ID: <200406071612490431.1B7F4FE7@136.179.85.112> In-Reply-To: <20040607111638.663de0a6@dell_ss3.pdx.osdl.net> References: <200406041451590078.0BC23855@136.179.85.112> <40C31C71.6000101@colorfullife.com> <200406071258550931.1ACDCC8B@136.179.85.112> <20040607111638.663de0a6@dell_ss3.pdx.osdl.net> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Mon, 07 Jun 2004 16:12:49 -0500 From: "Gary N Spiess" To: shemminger@osdl.org Cc: manfred@colorfullife.com, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i57LE1gi017120 X-archive-position: 5715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Gary.Spiess@Intermec.com Precedence: bulk X-list: netdev Content-Length: 896 Lines: 33 Stephen, Scrap patch 1 of 4, we don't need or want it. (I'm feeling so sheepish.) Thanks, Gary *********** REPLY SEPARATOR *********** On 6/7/2004 at 11:16 AM Stephen Hemminger wrote: >On Mon, 07 Jun 2004 12:58:55 -0500 >"Gary N Spiess" wrote: > >> Jeff, >> >> I agree with all comments. Regarding the total elimination of this >patch ... >> >> Only our bootrom knows the MAC address that should be used, and it >appends it to the bootargs. If there is a way for the userspace to take a >peek at the bootargs (or a similar mechanism), we can use the ifconfig >method to assign the MAC address instead of changing the driver. I'd >prefer it. > >/proc/cmdline?? oooooooooooooooooooooooooooooooooooooooooooooooooo Gary Spiess (Gary.Spiess@Intermec.com) MobileLan Wireless Products Group, Intermec Technology Corp voice: 319 369-3580 fax: 319 369-3804 From random@72616e646f6d20323030342d30342d31360a.nosense.org Mon Jun 7 14:43:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:43:05 -0700 (PDT) Received: from nosense.org (181.cust2.sa.dsl.ozemail.com.au [210.84.225.181]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Lgxgi020058 for ; Mon, 7 Jun 2004 14:43:00 -0700 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by nosense.org (Postfix) with SMTP id CD1153F0AD; Tue, 8 Jun 2004 07:12:52 +0930 (CST) Date: Tue, 8 Jun 2004 07:12:52 +0930 From: Mark Smith To: manfred@colorfullife.com, Gary.Spiess@Intermec.com, shemminger@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Message-Id: <20040608071252.77f9d69e.random@72616e646f6d20323030342d30342d31360a.nosense.org> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 965 Lines: 27 Hi Manfred, Gary, Stephen, "But: I'm not sure that the change is required. What about just setting the mac to 0, and the actual mac address is set from user space? It's possible to set the mac address with" Could I suggest if this is the solution implemented, setting the first octet of the MAC address to 0x02, as in a Locally Assigned MAC address ? If an interface with an all zero's MAC address is added to a bridge, running the Spanning Tree Protocol (STP), it will always attempt to take over as the root bridge, unless STP root bridge priorities are being used. This would disrupt traffic on the attached LAN. Ideally, assigning "zero" a MAC address which has almost no chance of disrupting STP or any other protocol could be useful. Maybe fe:ff:ff:ff:ff:ff ? I think this would fit in with the "be conservative in what you send, liberal in what you receive" philosophy. Regards, Mark. ps, please CC on any replies, I'm not subscribed to the list yet. From shemminger@osdl.org Mon Jun 7 14:47:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:47:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Ll6gi020397 for ; Mon, 7 Jun 2004 14:47:06 -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 i57Lksr14318; Mon, 7 Jun 2004 14:46:54 -0700 Date: Mon, 7 Jun 2004 14:46:54 -0700 From: Stephen Hemminger To: Mark Smith Cc: manfred@colorfullife.com, Gary.Spiess@Intermec.com, netdev@oss.sgi.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Message-Id: <20040607144654.540e7eee@dell_ss3.pdx.osdl.net> In-Reply-To: <20040608071252.77f9d69e.random@72616e646f6d20323030342d30342d31360a.nosense.org> References: <20040608071252.77f9d69e.random@72616e646f6d20323030342d30342d31360a.nosense.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: 5717 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: 1253 Lines: 33 On Tue, 8 Jun 2004 07:12:52 +0930 Mark Smith wrote: > Hi Manfred, Gary, Stephen, > > "But: I'm not sure that the change is required. What about just > setting the mac to 0, and the actual mac address is set from user > space? It's possible to set the mac address with" > > Could I suggest if this is the solution implemented, setting the > first octet of the MAC address to 0x02, as in a Locally Assigned > MAC address ? > > If an interface with an all zero's MAC address is added to a > bridge, running the Spanning Tree Protocol (STP), it will always > attempt to take over as the root bridge, unless STP root bridge > priorities are being used. This would disrupt traffic on the > attached LAN. Actually, it won't let you add any interface to a bridge without a valid ether address now (ie non-zero and not multicast). > Ideally, assigning "zero" a MAC address which has almost no > chance of disrupting STP or any other protocol could be useful. > Maybe fe:ff:ff:ff:ff:ff ? > > I think this would fit in with the "be conservative in what you > send, liberal in what you receive" philosophy. > > Regards, > Mark. > > ps, please CC on any replies, I'm not subscribed to the list yet. From shemminger@osdl.org Mon Jun 7 14:48:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 14:48:53 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Lmpgi020719 for ; Mon, 7 Jun 2004 14:48:51 -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 i57Lmar15262; Mon, 7 Jun 2004 14:48:36 -0700 Date: Mon, 7 Jun 2004 14:48:36 -0700 From: Stephen Hemminger To: Mark Smith Cc: manfred@colorfullife.com, Gary.Spiess@Intermec.com, netdev@oss.sgi.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Message-Id: <20040607144836.1796869d@dell_ss3.pdx.osdl.net> In-Reply-To: <20040608071252.77f9d69e.random@72616e646f6d20323030342d30342d31360a.nosense.org> References: <20040608071252.77f9d69e.random@72616e646f6d20323030342d30342d31360a.nosense.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: 5718 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: 402 Lines: 13 On Tue, 8 Jun 2004 07:12:52 +0930 Mark Smith wrote: > Hi Manfred, Gary, Stephen, > > "But: I'm not sure that the change is required. What about just > setting the mac to 0, and the actual mac address is set from user > space? It's possible to set the mac address with" How about random_ether_addr(dev->dev_addr); it does the right thing. From davem@redhat.com Mon Jun 7 15:00:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 15:00:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57M0Vgi021227 for ; Mon, 7 Jun 2004 15:00: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 i57M0Si5028807; Mon, 7 Jun 2004 18:00:28 -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 i57M0S010132; Mon, 7 Jun 2004 18:00:28 -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 i57M0GnE000573; Mon, 7 Jun 2004 18:00:16 -0400 Date: Mon, 7 Jun 2004 14:57:23 -0700 From: "David S. Miller" To: Roger Luethi Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics Message-Id: <20040607145723.41da5783.davem@redhat.com> In-Reply-To: <20040607212804.GA17012@k3.hellgate.ch> References: <20040607212804.GA17012@k3.hellgate.ch> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5719 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: 666 Lines: 19 On Mon, 7 Jun 2004 23:28:04 +0200 Roger Luethi wrote: > What is the correct response if a user passes ethtool speed or duplex > arguments while autoneg is on? Some possible answers are: > > a) Yell at the user for doing something stupid. > > b) Fail silently (i.e. ignore command). > > c) Change advertised value accordingly and initiate new negotiation. > > d) Consider "autoneg off" implied, force media accordingly. > > The ethtool(8) man page I'm looking at doesn't address that question. The > actual behavior I've seen is b) which is by far my least preferred > solution. speed and duplex fields should be silently ignored in this case From random@72616e646f6d20323030342d30342d31360a.nosense.org Mon Jun 7 15:11:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 15:11:19 -0700 (PDT) Received: from nosense.org (181.cust2.sa.dsl.ozemail.com.au [210.84.225.181]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57MBEgi021975 for ; Mon, 7 Jun 2004 15:11:15 -0700 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by nosense.org (Postfix) with SMTP id 637F73F0AD; Tue, 8 Jun 2004 07:41:06 +0930 (CST) Date: Tue, 8 Jun 2004 07:41:05 +0930 From: Mark Smith To: Stephen Hemminger Cc: manfred@colorfullife.com, Gary.Spiess@Intermec.com, netdev@oss.sgi.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address Message-Id: <20040608074105.217ff66c.random@72616e646f6d20323030342d30342d31360a.nosense.org> In-Reply-To: <20040607144654.540e7eee@dell_ss3.pdx.osdl.net> References: <20040608071252.77f9d69e.random@72616e646f6d20323030342d30342d31360a.nosense.org> <20040607144654.540e7eee@dell_ss3.pdx.osdl.net> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 1088 Lines: 38 On Mon, 7 Jun 2004 14:46:54 -0700 Stephen Hemminger wrote: > On Tue, 8 Jun 2004 07:12:52 +0930 > Mark Smith > > wrote: > > > Hi Manfred, Gary, Stephen, > > > > If an interface with an all zero's MAC address is added to a > > bridge, running the Spanning Tree Protocol (STP), it will > > always attempt to take over as the root bridge, unless STP > > root bridge priorities are being used. This would disrupt > > traffic on the attached LAN. > > Actually, it won't let you add any interface to a bridge > without a valid ether address now (ie non-zero and not > multicast). > That's good, I first noticed this issue when I happened to add a dummy interface into a bridge configuration, and found that its zero MAC address ended up disrupting the spanning tree. I also have just noticed that the dummy interfaces now have random MAC addresses as per the function you mentioned earlier. Also good. Regards, Mark. > > > > ps, please CC on any replies, I'm not subscribed to the list > > yet. From davem@redhat.com Mon Jun 7 15:30:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 15:30:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57MU9gi022944 for ; Mon, 7 Jun 2004 15:30: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 i57MU5i5002412; Mon, 7 Jun 2004 18:30:05 -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 i57MU5017856; Mon, 7 Jun 2004 18:30:05 -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 i57MTrLu011227; Mon, 7 Jun 2004 18:29:53 -0400 Date: Mon, 7 Jun 2004 15:27:00 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] add receive DRS info Message-Id: <20040607152700.7f9252a1.davem@redhat.com> In-Reply-To: <20040607100744.1b67baa2@dell_ss3.pdx.osdl.net> References: <20040604153749.5d8a13b9@dell_ss3.pdx.osdl.net> <20040604205749.11725598.davem@redhat.com> <20040607100744.1b67baa2@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5721 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: 417 Lines: 10 On Mon, 7 Jun 2004 10:07:44 -0700 Stephen Hemminger wrote: > Add receiver feedback information to the tcp_info structure to allow > looking at receive dynamic right sizing with 'ss' command. > > This increases the size of the structure, but since both getsockopt() and netlink > interface pass length in request; it retains compatibility with older versions. Right, applied. Thanks Stephen. From rl@hellgate.ch Mon Jun 7 15:54:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 15:54:09 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Ms5gi024180 for ; Mon, 7 Jun 2004 15:54:06 -0700 Received: from k3.hellgate.ch (83.76.121.213) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C000D5D6A; Sun, 6 Jun 2004 16:53:29 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id EDDF08B29E8; Sun, 6 Jun 2004 18:53:28 +0200 (CEST) Date: Sun, 6 Jun 2004 18:53:28 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [1/3][PATCH 2.6] via-rhine: fix mc_filter on big-endian arch Message-ID: <20040606165328.GA13733@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 746 Lines: 19 A.J. from VIA Networking Technologies noticed that via-rhine is using cpu_to_le32() when preparing mc_filter hashes. This breaks Rhine hardware multicast filters on big-endian architectures. Please apply. Signed-off-by: Roger Luethi --- 2.6-bk/drivers/net/via-rhine.c.orig 2004-06-06 18:03:21.323194221 +0200 +++ 2.6-bk/drivers/net/via-rhine.c 2004-06-06 18:05:22.137319854 +0200 @@ -1782,7 +1782,7 @@ i++, mclist = mclist->next) { int bit_nr = ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26; - mc_filter[bit_nr >> 5] |= cpu_to_le32(1 << (bit_nr & 31)); + mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31); } writel(mc_filter[0], ioaddr + MulticastFilter0); writel(mc_filter[1], ioaddr + MulticastFilter1); From ak@suse.de Mon Jun 7 15:58:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 15:58:36 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57MwWgi024592 for ; Mon, 7 Jun 2004 15:58: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 261F16AFA18; Tue, 8 Jun 2004 00:58:26 +0200 (CEST) Date: Tue, 8 Jun 2004 00:58:25 +0200 From: Andi Kleen To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , James Ketrenos Subject: Re: Fwd: in-driver QoS Message-ID: <20040607225825.GA30647@wotan.suse.de> References: <200406072217.31924.vkondra@mail.ru> <40C4C42F.2040006@pobox.com> <200406072328.23836.vkondra@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406072328.23836.vkondra@mail.ru> X-archive-position: 5723 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: 191 Lines: 6 > I know very little about ATM, but it have QoS, both diff serv and int serv. > May be it is worth to borrow from it? ATM and IP diffserv just use the qdisc framework in the kernel. -Andi From ak@suse.de Mon Jun 7 15:59:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 15:59:33 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57MxTgi024900 for ; Mon, 7 Jun 2004 15:59:30 -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 44B9D6AFA3E; Tue, 8 Jun 2004 00:59:24 +0200 (CEST) Date: Tue, 8 Jun 2004 00:59:23 +0200 From: Andi Kleen To: Vladimir Kondratiev Cc: netdev@oss.sgi.com Subject: Re: in-driver QoS Message-Id: <20040608005923.408ddf21.ak@suse.de> In-Reply-To: <200406072335.04125.vkondra@mail.ru> References: <200406062128.47070.vkondra@mail.ru> <20040607140011.GC28639@wotan.suse.de> <200406072335.04125.vkondra@mail.ru> 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: 5724 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: 463 Lines: 12 On Mon, 7 Jun 2004 23:35:04 +0300 Vladimir Kondratiev wrote: > How could I use these multiple qdiscs? If I use existing driver framework, I > have hard_start_xmit, that represent single queue. Do you have any examples > how driver can access qdiscs directly? I.e. I have 4 queues in the driver, I > want to fill it separately, start/stop incoming queues from stack etc. Normally it would be configured by the user tools (using tc) -Andi From davem@redhat.com Mon Jun 7 16:20:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 16:20:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57NKogi029543 for ; Mon, 7 Jun 2004 16:20:50 -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 i57NKli5013061; Mon, 7 Jun 2004 19:20: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 i57NKl030987; Mon, 7 Jun 2004 19:20: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 i57NKZvp027585; Mon, 7 Jun 2004 19:20:35 -0400 Date: Mon, 7 Jun 2004 16:17:41 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] unclamp tcp receive window if doing dynamic receive sizing Message-Id: <20040607161741.1f295aca.davem@redhat.com> In-Reply-To: <20040607133056.5ab9e72d@dell_ss3.pdx.osdl.net> References: <20040607133056.5ab9e72d@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5726 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: 695 Lines: 17 On Mon, 7 Jun 2004 13:30:56 -0700 Stephen Hemminger wrote: > When running tests over higher speed links, the new 2.6 Dynamic Receiver Sizing > code doesn't increase the window large enough. The problem is that the window > clamp restricts the allowed window to the socket receive buffer size (85k) > > Easiest fix is to not restrict window clamp if we want to dynamic receiver stuff. > This is what web100 did. > > Thanks to John Heffner for finding this. This turns off all tcp_app_win semantics, are you sure that tcp_app_win makes no sense when doing dynamic receive buffer sizing? I think we should still factor it in, perhaps dynamically, during rcvbuf growth. From marc.herbert@free.fr Mon Jun 7 16:59:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 16:59:05 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Nwpgi030994 for ; Mon, 7 Jun 2004 16:58:51 -0700 Received: from mutualite-3-82-67-66-29.fbx.proxad.net (mutualite-3-82-67-66-29.fbx.proxad.net [82.67.66.29]) by postfix4-1.free.fr (Postfix) with ESMTP id 4E13212B2C1; Tue, 8 Jun 2004 01:43:16 +0200 (CEST) Date: Tue, 8 Jun 2004 01:43:26 +0200 (CEST) From: Marc Herbert X-X-Sender: mherbert@fcat To: netdev@oss.sgi.com Cc: Roger Luethi , linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics In-Reply-To: <20040607145723.41da5783.davem@redhat.com> Message-ID: References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> 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 i57Nwpgi030994 X-archive-position: 5727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc.herbert@free.fr Precedence: bulk X-list: netdev Content-Length: 1652 Lines: 45 On Mon, 7 Jun 2004, David S. Miller wrote: > On Mon, 7 Jun 2004 23:28:04 +0200 > Roger Luethi wrote: > > > What is the correct response if a user passes ethtool speed or duplex > > arguments while autoneg is on? Some possible answers are: > > > > a) Yell at the user for doing something stupid. > > > > b) Fail silently (i.e. ignore command). > > > > c) Change advertised value accordingly and initiate new negotiation. > > > > d) Consider "autoneg off" implied, force media accordingly. > > > > The ethtool(8) man page I'm looking at doesn't address that question. The > > actual behavior I've seen is b) which is by far my least preferred > > solution. > speed and duplex fields should be silently ignored in this case I find the c) feature very convenient. For instance it allows reliably downgrading a link connected to a switch without having to fiddle with the configuration of the switch, something which is usually (pick your favourites) non-standard, painful, not authorized, not implemented, buggy,... Command line parameters of the bcm5700driver do implement c) (among other nifties). Documented in its man page. Command line parameters of e1000 also allow some control over the autonegociation process, even if not using c) but a different (and less user-friendly) syntax. See Documentation/--/e1000.txt. From David's words, I suspect this feature is simply missing from ethtool. Finally, silently ignoring user input is not very user-friendly IMHO. I would much prefer a) to b). I am aware that my preferences are probably in inverse order of the amount of work required. PS: I read netdev but not linux-kernel From jt@bougret.hpl.hp.com Mon Jun 7 18:01:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 18:01:50 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5811agi001353 for ; Mon, 7 Jun 2004 18:01:36 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 8C2BE9F2E; Mon, 7 Jun 2004 17:27:00 -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 RAA22225; Mon, 7 Jun 2004 17:28:08 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BXUSB-0005SI-00; Mon, 07 Jun 2004 17:26:59 -0700 Date: Mon, 7 Jun 2004 17:26:59 -0700 To: Jouni Malinen Cc: netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support Message-ID: <20040608002659.GA18087@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040607023455.GA10424@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607023455.GA10424@jm.kir.nu> 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: 5729 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: 4787 Lines: 113 On Sun, Jun 06, 2004 at 07:34:55PM -0700, Jouni Malinen wrote: > > I started working on WPA extension for the Linux wireless extensions > based on our earlier discussion. This patch file for V16 shows my > current work version. It is not yet ready to be merged into any tree and > is here mainly to allow review of the changes and generate some > discussion (and well, to describe the changes without me having to write > a long email doing that ;-). Thanks a lot for that, Jouni ! > This has not yet been tested, but I'm starting to add support for it > into the wireless-2.6 version of Host AP driver and wpa_supplicant. I'll > make an updated patch available once everything seems to be working. > > To avoid using much more ioctl numbers, I extended the previously > defined SIOCSIWENCODE/SIOCGIWENCODE and SIOCSIWSCAN instead of defining > new ioctls. Actually, I don't like the extension of SIOC*IWENCODE. This ioctl is already messy/complex enough as it is, and I think we would benefit greatly in separating the two code paths, therefore using a new iotcl for it. It's not like we are short of ioctls. I'm worried about new-style driver returning extended definition to old style tools, or new style tool sending extended definitions to old style driver, or other stuff like that. Also, driver author may thank us for keeping thing clearer. The extension of SIOCSIWSCAN was always something desired, but I never got sure of which way it was supposed to be done (look at the unused IW_SCAN_* flags in wireless.h). Do you think that ESSID is the only request filter that is worthwhile ? Another option would be to allow an "iwevent" structure allow to specify any kind of filter. If we decide that we will only ever filter on ESSID, then I still don't understand the way you plan to use iw_scan_req. It doesn't fit in 16 bytes, so it will be used with a struct iw_point/IW_HEADER_TYPE_POINT. In such a case, the "ssid_len" is redundant with "length" in iw_point. If we remove "ssid_len", then the format is exactly the same as SIOCSIWESSID, which make things nice and simple. > Similarily, SIOCSIWAUTH/SIOCGIWAUTH uses one pair of ioctls > to allow configuring multiple (4096) different parameters. It took me a while to understand how this one is supposed to works (which means that it may need better documentation). It's a sub-ioctl kind of thing, right ? The SET accept two 32 bit integers, the GET accept one and return one. You current definition doesn't work, because you are using IW_HEADER_TYPE_PARAM that carry only a single 32bit integer. There are two solutions. The first is fit the IW_AUTH_INDEX in the 16 bits of iw_param->flags. The second is to use IW_HEADER_TYPE_UINT. Also, all the constant used for this command should have the IW_AUTH_* prefix (IW_CIPHER_NONE => IW_AUTH_CIPHER_NONE), so that we can see clearly that they apply to this command. I would even go futher and have common prefixes between request and values : --- #define IW_AUTH_WPA_VERSION 0 --- #define IW_AUTH_WPA_VERSION_DISABLED 0 #define IW_AUTH_WPA_VERSION_WPA 1 #define IW_AUTH_WPA_VERSION_WPA2 2 --- #define IW_AUTH_CIPHER_PAIRWISE 1 #define IW_AUTH_CIPHER_GROUP 2 --- #define IW_AUTH_CIPHER_NONE 0 #define IW_AUTH_CIPHER_WEP40 1 #define IW_AUTH_CIPHER_TKIP 2 #define IW_AUTH_CIPHER_CCMP 4 #define IW_AUTH_CIPHER_WEP104 5 --- I think this would read much better, and avoid the need to extra documentation. > supported_features bit field in struct iw_range will be used by the WPA > Supplicant to determine which modes can be used with the current driver. I think that "supported_feature" is too generic a name for what you are using it now. As there are other "supported_feature" type of fields in iw_range (pm_capa, txpower_capa, retry_capa), I would suggest to use a more descriptive name, such as "enc_features" or "enc_capa". > Comments are very much welcome, especially from other authors of > wireless device driver. I went through the wpa_supplicant driver > interface and tried to include everything needed here. However, I did > not yet verify whether some of the existing driver interfaces would > benefit from additional fields in wireless extensions. Well, this is where we hope the "extension" part of "wireless extensions" works as advertised, and hopefully we can just add the necessary features later on. > +/* IEEE 802.11 MLME requests */ > +#define SIOCSIWMLME 0x8B30 /* request MLME operation */ I don't see a struct for it, so I assume the format of that is defined somewhere in the 802.11 spec ? May be worth documenting where to look for it. > Jouni Malinen I hope I did not sound too "picky", but I hope that my suggestion are not too difficult to implement while adding some value. Tell me what you think ;-) Have fun... Jean From yoshfuji@linux-ipv6.org Mon Jun 7 20:07:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 20:07:34 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5837Ugi005616 for ; Mon, 7 Jun 2004 20:07:31 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 09FA633CE5; Tue, 8 Jun 2004 12:08:18 +0900 (JST) Date: Tue, 08 Jun 2004 12:08:17 +0900 (JST) Message-Id: <20040608.120817.49979734.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [IPV6] IP6CB 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: 5730 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: 7080 Lines: 200 Introduce IP6CB(skb), like other protocols such as IPv4. ===== include/linux/ipv6.h 1.19 vs edited ===== --- 1.19/include/linux/ipv6.h 2004-02-17 15:49:11 +09:00 +++ edited/include/linux/ipv6.h 2004-06-08 11:48:25 +09:00 @@ -192,6 +192,8 @@ __u16 dst1; }; +#define IP6CB(skb) ((struct inet6_skb_parm*)((skb)->cb)) + struct ipv6_pinfo { struct in6_addr saddr; struct in6_addr rcv_saddr; ===== net/ipv6/datagram.c 1.16 vs edited ===== --- 1.16/net/ipv6/datagram.c 2004-04-17 05:54:43 +09:00 +++ edited/net/ipv6/datagram.c 2004-06-08 11:57:21 +09:00 @@ -145,10 +145,8 @@ (struct in6_addr *)(skb->nh.raw + serr->addr_offset)); if (np->sndflow) sin->sin6_flowinfo = *(u32*)(skb->nh.raw + serr->addr_offset - 24) & IPV6_FLOWINFO_MASK; - if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) { - struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; - sin->sin6_scope_id = opt->iif; - } + if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) + sin->sin6_scope_id = IP6CB(skb)->iif; } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, htonl(0xffff), @@ -167,10 +165,8 @@ ipv6_addr_copy(&sin->sin6_addr, &skb->nh.ipv6h->saddr); if (np->rxopt.all) datagram_recv_ctl(sk, msg, skb); - if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) { - struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; - sin->sin6_scope_id = opt->iif; - } + if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) + sin->sin6_scope_id = IP6CB(skb)->iif; } else { struct inet_opt *inet = inet_sk(sk); @@ -211,7 +207,7 @@ int datagram_recv_ctl(struct sock *sk, struct msghdr *msg, struct sk_buff *skb) { struct ipv6_pinfo *np = inet6_sk(sk); - struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; + struct inet6_skb_parm *opt = IP6CB(skb); if (np->rxopt.bits.rxinfo) { struct in6_pktinfo src_info; ===== net/ipv6/exthdrs.c 1.25 vs edited ===== --- 1.25/net/ipv6/exthdrs.c 2004-06-01 16:22:49 +09:00 +++ edited/net/ipv6/exthdrs.c 2004-06-08 11:51:57 +09:00 @@ -155,7 +155,7 @@ static int ipv6_destopt_rcv(struct sk_buff **skbp, unsigned int *nhoffp) { struct sk_buff *skb = *skbp; - struct inet6_skb_parm *opt = (struct inet6_skb_parm *)skb->cb; + struct inet6_skb_parm *opt = IP6CB(skb); if (!pskb_may_pull(skb, (skb->h.raw-skb->data)+8) || !pskb_may_pull(skb, (skb->h.raw-skb->data)+((skb->h.raw[1]+1)<<3))) { @@ -217,7 +217,7 @@ static int ipv6_rthdr_rcv(struct sk_buff **skbp, unsigned int *nhoffp) { struct sk_buff *skb = *skbp; - struct inet6_skb_parm *opt = (struct inet6_skb_parm *)skb->cb; + struct inet6_skb_parm *opt = IP6CB(skb); struct in6_addr *addr; struct in6_addr daddr; int n, i; @@ -288,7 +288,7 @@ return -1; } *skbp = skb = skb2; - opt = (struct inet6_skb_parm *)skb2->cb; + opt = IP6CB(skb2); hdr = (struct ipv6_rt_hdr *) skb2->h.raw; } @@ -418,7 +418,7 @@ static int ipv6_hop_ra(struct sk_buff *skb, int optoff) { if (skb->nh.raw[optoff+1] == 2) { - ((struct inet6_skb_parm*)skb->cb)->ra = optoff; + IP6CB(skb)->ra = optoff; return 1; } LIMIT_NETDEBUG( @@ -482,7 +482,7 @@ int ipv6_parse_hopopts(struct sk_buff *skb, int nhoff) { - ((struct inet6_skb_parm*)skb->cb)->hop = sizeof(struct ipv6hdr); + IP6CB(skb)->hop = sizeof(struct ipv6hdr); if (ip6_parse_tlv(tlvprochopopt_lst, skb)) return sizeof(struct ipv6hdr); return -1; ===== net/ipv6/ip6_input.c 1.19 vs edited ===== --- 1.19/net/ipv6/ip6_input.c 2004-06-01 16:22:49 +09:00 +++ edited/net/ipv6/ip6_input.c 2004-06-08 11:52:42 +09:00 @@ -74,7 +74,7 @@ /* Store incoming device index. When the packet will be queued, we cannot refer to skb->dev anymore. */ - ((struct inet6_skb_parm *)skb->cb)->iif = dev->ifindex; + IP6CB(skb)->iif = dev->ifindex; if (skb->len < sizeof(struct ipv6hdr)) goto err; ===== net/ipv6/ip6_output.c 1.58 vs edited ===== --- 1.58/net/ipv6/ip6_output.c 2004-06-04 14:02:47 +09:00 +++ edited/net/ipv6/ip6_output.c 2004-06-08 11:52:52 +09:00 @@ -349,7 +349,7 @@ { struct dst_entry *dst = skb->dst; struct ipv6hdr *hdr = skb->nh.ipv6h; - struct inet6_skb_parm *opt =(struct inet6_skb_parm*)skb->cb; + struct inet6_skb_parm *opt = IP6CB(skb); if (ipv6_devconf.forwarding == 0) goto error; ===== net/ipv6/raw.c 1.61 vs edited ===== --- 1.61/net/ipv6/raw.c 2004-06-01 16:22:49 +09:00 +++ edited/net/ipv6/raw.c 2004-06-08 11:53:09 +09:00 @@ -409,10 +409,8 @@ ipv6_addr_copy(&sin6->sin6_addr, &skb->nh.ipv6h->saddr); sin6->sin6_flowinfo = 0; sin6->sin6_scope_id = 0; - if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) { - struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; - sin6->sin6_scope_id = opt->iif; - } + if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) + sin6->sin6_scope_id = IP6CB(skb)->iif; } sock_recv_timestamp(msg, sk, skb); ===== net/ipv6/tcp_ipv6.c 1.81 vs edited ===== --- 1.81/net/ipv6/tcp_ipv6.c 2004-05-20 15:27:57 +09:00 +++ edited/net/ipv6/tcp_ipv6.c 2004-06-08 11:55:02 +09:00 @@ -536,8 +536,7 @@ static __inline__ int tcp_v6_iif(struct sk_buff *skb) { - struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; - return opt->iif; + return IP6CB(skb)->iif; } static int tcp_v6_connect(struct sock *sk, struct sockaddr *uaddr, @@ -879,7 +878,7 @@ np->rxopt.bits.srcrt == 2 && req->af.v6_req.pktopts) { struct sk_buff *pktopts = req->af.v6_req.pktopts; - struct inet6_skb_parm *rxopt = (struct inet6_skb_parm *)pktopts->cb; + struct inet6_skb_parm *rxopt = IP6CB(pktopts); if (rxopt->srcrt) opt = ipv6_invert_rthdr(sk, (struct ipv6_rt_hdr*)(pktopts->nh.raw + rxopt->srcrt)); } @@ -932,7 +931,7 @@ static int ipv6_opt_accepted(struct sock *sk, struct sk_buff *skb) { struct ipv6_pinfo *np = inet6_sk(sk); - struct inet6_skb_parm *opt = (struct inet6_skb_parm *)skb->cb; + struct inet6_skb_parm *opt = IP6CB(skb); if (np->rxopt.all) { if ((opt->hop && np->rxopt.bits.hopopts) || @@ -1305,7 +1304,7 @@ if (np->rxopt.bits.srcrt == 2 && opt == NULL && req->af.v6_req.pktopts) { - struct inet6_skb_parm *rxopt = (struct inet6_skb_parm *)req->af.v6_req.pktopts->cb; + struct inet6_skb_parm *rxopt = IP6CB(req->af.v6_req.pktopts); if (rxopt->srcrt) opt = ipv6_invert_rthdr(sk, (struct ipv6_rt_hdr*)(req->af.v6_req.pktopts->nh.raw+rxopt->srcrt)); } ===== net/ipv6/udp.c 1.63 vs edited ===== --- 1.63/net/ipv6/udp.c 2004-05-30 06:47:37 +09:00 +++ edited/net/ipv6/udp.c 2004-06-08 11:55:30 +09:00 @@ -432,10 +432,8 @@ if (np->rxopt.all) datagram_recv_ctl(sk, msg, skb); - if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) { - struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; - sin6->sin6_scope_id = opt->iif; - } + if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) + sin6->sin6_scope_id = IP6CB(skb)->iif; } } err = copied; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From hadi@cyberus.ca Mon Jun 7 20:24:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 20:25:00 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i583Owgi009928 for ; Mon, 7 Jun 2004 20:24:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BXTi7-0007vO-HC for netdev@oss.sgi.com; Mon, 07 Jun 2004 19:39:23 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BXThz-00077j-RN; Mon, 07 Jun 2004 19:39:16 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Andi Kleen In-Reply-To: <200406072335.04125.vkondra@mail.ru> References: <200406062128.47070.vkondra@mail.ru> <20040607140011.GC28639@wotan.suse.de> <200406072335.04125.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086651524.1037.10.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jun 2004 19:38:44 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5732 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: 858 Lines: 21 On Mon, 2004-06-07 at 16:35, Vladimir Kondratiev wrote: > How could I use these multiple qdiscs? If I use existing driver framework, I > have hard_start_xmit, that represent single queue. Do you have any examples > how driver can access qdiscs directly? I.e. I have 4 queues in the driver, I > want to fill it separately, start/stop incoming queues from stack etc. Maybe you can explain a little more: Do these 4 queues translate to 4 DMA rings or channles on the NIC? Could you not use a tag like fwmark to select DMA to send to? Explain the packet path once it hits the driver. > Note also, we are talking about 100Mbps above MAC, which translates to about > 150 Mbps, within next 2 years. 100Mbps above MAC is criteria for TGn working > group in IEEE (high throughput). Are these wireless NICs? Whats the big deal about 150Mbps? cheers, jamal From manfred@colorfullife.com Mon Jun 7 22:30:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 22:30:31 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i585USgi013351 for ; Mon, 7 Jun 2004 22:30:29 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i585UKLw001087; Tue, 8 Jun 2004 07:30:21 +0200 Message-ID: <40C54EE9.3090901@colorfullife.com> Date: Tue, 08 Jun 2004 07:30:17 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary N Spiess CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] natsemi update 3/4 External PHY operation References: <200406041455290031.0BC56C76@136.179.85.112> <40C33D38.1060102@colorfullife.com> <200406071608450571.1B7B9754@136.179.85.112> In-Reply-To: <200406071608450571.1B7B9754@136.179.85.112> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5733 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: 998 Lines: 19 Gary N Spiess wrote: >The existing driver code was already written to reference the "current PHY" with address 1. To select a different address to represent the current PHY would have required me to touch more lines of source. > > > Then touch more lines of source - the patch as it is is unreadable. >- The partial reset fix (again, to the best of my knowledge) is only needed when the internal PHY being used has reset, but the MAC has not. The dspcfg != np->dspcfg test identifies an internal PHY that has been reset, and triggers the driver to do a a complete MAC/PHY reset. When using an external PHY, the test continually causes unneeded resets. The change to set np->dspcfg to 0 prevents it. This was the minimal change to get the desired results. > Again, miminal change doesn't matter. Add a + if (dev->if_port != PORT_TP) return; into {do,undo}_cable_magic() and netdev_timer(). Perhaps with a comment that the following block is specific to the internal PHY. -- Manfred From vkondra@mail.ru Mon Jun 7 22:41:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jun 2004 22:41:31 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i585fRgi014019 for ; Mon, 7 Jun 2004 22:41:28 -0700 Received: from [212.179.218.36] (port=14943 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BXZMS-000Mzl-00; Tue, 08 Jun 2004 09:41:26 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: in-driver QoS Date: Tue, 8 Jun 2004 08:41:14 +0300 User-Agent: KMail/1.6.2 Cc: Andi Kleen References: <200406062128.47070.vkondra@mail.ru> <200406072335.04125.vkondra@mail.ru> <1086651524.1037.10.camel@jzny.localdomain> In-Reply-To: <1086651524.1037.10.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406080841.14579.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5735 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: 1742 Lines: 35 On Tuesday 08 June 2004 02:38, jamal wrote: > On Mon, 2004-06-07 at 16:35, Vladimir Kondratiev wrote: > > How could I use these multiple qdiscs? If I use existing driver > > framework, I have hard_start_xmit, that represent single queue. Do you > > have any examples how driver can access qdiscs directly? I.e. I have 4 > > queues in the driver, I want to fill it separately, start/stop incoming > > queues from stack etc. > > Maybe you can explain a little more: Do these 4 queues translate to 4 Exactly > DMA rings or channles on the NIC? Could you not use a tag like fwmark to > select DMA to send to? > Explain the packet path once it hits the driver. Let's put aside integrated service. For diff serv, NIC have 4 DMA queues. These 4 queues acts as 4 independent 802.11 channels with different backoff and contention window parameters. Actually, it is dictated by TGe, and should be common for wireless stack. Queue consumption depends on conditions on air and access point settings. Access point set these different parameters for queues, and may change it time to time. I think it would be not good to rely on 'tc' to provide proper mix of packets. Meanwhile, it is what I use, but it is not proper solution. > > > Note also, we are talking about 100Mbps above MAC, which translates to > > about 150 Mbps, within next 2 years. 100Mbps above MAC is criteria for > > TGn working group in IEEE (high throughput). > > Are these wireless NICs? Whats the big deal about 150Mbps? Nothing special, but Andi mentioned that ... > Disadvantage will be more use of CPU time to refill driver > queues, but at the relatively slow WLAN speeds that shouldn't > be a big issue. ... and I want to note that it is not very slow network. Vladimir. From joe.andonieh@intel.com Tue Jun 8 00:36:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 00:36:50 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i587adgi021635 for ; Tue, 8 Jun 2004 00:36:41 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i587bbRg000990; Tue, 8 Jun 2004 07:37:37 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i587b6TA020681; Tue, 8 Jun 2004 07:37:08 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060810362526973 ; Tue, 08 Jun 2004 10:36:25 +0300 Received: from hasmsx402.ger.corp.intel.com ([143.185.63.156]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 10:36:26 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: RFC: Linux wireless extensions and WPA support Date: Tue, 8 Jun 2004 10:36:25 +0300 Message-ID: <386CBF9421521B41835E2BF21BEF80B8919069@hasmsx402.ger.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: Linux wireless extensions and WPA support Thread-Index: AcRM9FUQw4M81b0QT8ip+1ymrUkLdAAKoqag From: "Andonieh, Joe" To: Cc: , "Jouni Malinen" X-OriginalArrivalTime: 08 Jun 2004 07:36:26.0457 (UTC) FILETIME=[4E39F490:01C44D2B] 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 i587adgi021635 X-archive-position: 5736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joe.andonieh@intel.com Precedence: bulk X-list: netdev Content-Length: 5879 Lines: 159 #define IW_AUTH_WPA_VERSION 0 --- #define IW_AUTH_WPA_VERSION_DISABLED 0 #define IW_AUTH_WPA_VERSION_WPA 1 #define IW_AUTH_WPA_VERSION_WPA2 2 --- #define IW_AUTH_CIPHER_PAIRWISE 1 #define IW_AUTH_CIPHER_GROUP 2 --- #define IW_AUTH_CIPHER_NONE 0 #define IW_AUTH_CIPHER_WEP40 1 #define IW_AUTH_CIPHER_TKIP 2 #define IW_AUTH_CIPHER_CCMP 4 #define IW_AUTH_CIPHER_WEP104 5 I wonder how this definition let you differentiate between the unicast cipher and the group cipher? Moreover there is two information that are needed 1) the authentication model, which is PSK or .1x 2) The cipher to connect with? Shall we set both Pair wise and Group or only Pairwise and connect with what ever group cipher in the RSN IE -- hint this will enable smooth connection to mixed mode networks? Please let me know what you think? Thanks Joe -----Original Message----- From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Jean Tourrilhes Sent: Tuesday, June 08, 2004 3:27 AM To: Jouni Malinen Cc: netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support On Sun, Jun 06, 2004 at 07:34:55PM -0700, Jouni Malinen wrote: > > I started working on WPA extension for the Linux wireless extensions > based on our earlier discussion. This patch file for V16 shows my > current work version. It is not yet ready to be merged into any tree and > is here mainly to allow review of the changes and generate some > discussion (and well, to describe the changes without me having to write > a long email doing that ;-). Thanks a lot for that, Jouni ! > This has not yet been tested, but I'm starting to add support for it > into the wireless-2.6 version of Host AP driver and wpa_supplicant. I'll > make an updated patch available once everything seems to be working. > > To avoid using much more ioctl numbers, I extended the previously > defined SIOCSIWENCODE/SIOCGIWENCODE and SIOCSIWSCAN instead of defining > new ioctls. Actually, I don't like the extension of SIOC*IWENCODE. This ioctl is already messy/complex enough as it is, and I think we would benefit greatly in separating the two code paths, therefore using a new iotcl for it. It's not like we are short of ioctls. I'm worried about new-style driver returning extended definition to old style tools, or new style tool sending extended definitions to old style driver, or other stuff like that. Also, driver author may thank us for keeping thing clearer. The extension of SIOCSIWSCAN was always something desired, but I never got sure of which way it was supposed to be done (look at the unused IW_SCAN_* flags in wireless.h). Do you think that ESSID is the only request filter that is worthwhile ? Another option would be to allow an "iwevent" structure allow to specify any kind of filter. If we decide that we will only ever filter on ESSID, then I still don't understand the way you plan to use iw_scan_req. It doesn't fit in 16 bytes, so it will be used with a struct iw_point/IW_HEADER_TYPE_POINT. In such a case, the "ssid_len" is redundant with "length" in iw_point. If we remove "ssid_len", then the format is exactly the same as SIOCSIWESSID, which make things nice and simple. > Similarily, SIOCSIWAUTH/SIOCGIWAUTH uses one pair of ioctls > to allow configuring multiple (4096) different parameters. It took me a while to understand how this one is supposed to works (which means that it may need better documentation). It's a sub-ioctl kind of thing, right ? The SET accept two 32 bit integers, the GET accept one and return one. You current definition doesn't work, because you are using IW_HEADER_TYPE_PARAM that carry only a single 32bit integer. There are two solutions. The first is fit the IW_AUTH_INDEX in the 16 bits of iw_param->flags. The second is to use IW_HEADER_TYPE_UINT. Also, all the constant used for this command should have the IW_AUTH_* prefix (IW_CIPHER_NONE => IW_AUTH_CIPHER_NONE), so that we can see clearly that they apply to this command. I would even go futher and have common prefixes between request and values : --- #define IW_AUTH_WPA_VERSION 0 --- #define IW_AUTH_WPA_VERSION_DISABLED 0 #define IW_AUTH_WPA_VERSION_WPA 1 #define IW_AUTH_WPA_VERSION_WPA2 2 --- #define IW_AUTH_CIPHER_PAIRWISE 1 #define IW_AUTH_CIPHER_GROUP 2 --- #define IW_AUTH_CIPHER_NONE 0 #define IW_AUTH_CIPHER_WEP40 1 #define IW_AUTH_CIPHER_TKIP 2 #define IW_AUTH_CIPHER_CCMP 4 #define IW_AUTH_CIPHER_WEP104 5 --- I think this would read much better, and avoid the need to extra documentation. > supported_features bit field in struct iw_range will be used by the WPA > Supplicant to determine which modes can be used with the current driver. I think that "supported_feature" is too generic a name for what you are using it now. As there are other "supported_feature" type of fields in iw_range (pm_capa, txpower_capa, retry_capa), I would suggest to use a more descriptive name, such as "enc_features" or "enc_capa". > Comments are very much welcome, especially from other authors of > wireless device driver. I went through the wpa_supplicant driver > interface and tried to include everything needed here. However, I did > not yet verify whether some of the existing driver interfaces would > benefit from additional fields in wireless extensions. Well, this is where we hope the "extension" part of "wireless extensions" works as advertised, and hopefully we can just add the necessary features later on. > +/* IEEE 802.11 MLME requests */ > +#define SIOCSIWMLME 0x8B30 /* request MLME operation */ I don't see a struct for it, so I assume the format of that is defined somewhere in the 802.11 spec ? May be worth documenting where to look for it. > Jouni Malinen I hope I did not sound too "picky", but I hope that my suggestion are not too difficult to implement while adding some value. Tell me what you think ;-) Have fun... Jean From marc.herbert@free.fr Tue Jun 8 02:39:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 02:40:00 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i589dlgi026884 for ; Tue, 8 Jun 2004 02:39:47 -0700 Received: from mutualite-3-82-67-66-29.fbx.proxad.net (mutualite-3-82-67-66-29.fbx.proxad.net [82.67.66.29]) by postfix4-1.free.fr (Postfix) with ESMTP id 9366B12C499 for ; Tue, 8 Jun 2004 10:50:38 +0200 (CEST) Date: Tue, 8 Jun 2004 10:50:49 +0200 (CEST) From: Marc Herbert X-X-Sender: mherbert@fcat To: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time (fwd) Message-ID: 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 i589dlgi026884 X-archive-position: 5740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc.herbert@free.fr Precedence: bulk X-list: netdev Content-Length: 2103 Lines: 53 On Fri, 4 Jun 2004, Scott Feldman wrote: > I see no reason to keep the non-NAPI option for e100. This patch removes > the CONFIG_E100_NAPI option and puts the driver in NAPI mode all the time. > Matches the way tg3 works. > > Unless someone has a really good reason to keep the non-NAPI mode, this > should go in for 2.6.7. Scott, If I understand pre-NAPI history correctly (please anyone correct me), the rationale/reason for the old, "backlog" SW FIFO design was to cope with network bursts in the following context: (1) transient network throughput higher than what the CPU could manage (2) number of RxDescriptors (i.e., FIFO available to the NIC) too small to cope with this burst on the NIC. Point (2) calls for freeing the NIC urgently, and point (1) calls for _not_ processing each received packet all the way up immediatly with an high priority, but doing a minimal amount of work instead, defering the rest and quickly buffering the burst, hoping for quieter times later. Thus the pre-NAPI intermediate backlog queue. Removing some queue may remove the ability to cope with transient bursts, if another queue is not able to fulfill the role of the disappeared one. Since you cannot make assumptions about the network/CPU balance (people can stick any NICs in any machine they have, even old and slow and overloaded ones) point (1) may still be true today. So the removal of the non-API option for e100assumes that point (2) is now always false. That is: the RxDescriptors queue is big enough to cope with transient network bursts; every e100 NIC can buffer these bursts by itself without any help from the kernel backlog. So two questions considering the point of view of non-NAPI e100 users "forced" to migrate to NAPI - for basic users, is the _default_ RxDescriptors "high enough", compared to the backlog dampering they were used to ? - for advanced users, is the _maximum_ RxDescriptors "high enough"? compared to the backlog dampering they were used to ? My 2 cents (you asked for them :-) Thanks in advance for pointing out over-simplications above. Marc. From cchan@outblaze.com Tue Jun 8 02:53:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 02:53:23 -0700 (PDT) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i589rKgi029796 for ; Tue, 8 Jun 2004 02:53:21 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id A868237AE5; Tue, 8 Jun 2004 09:53:18 +0000 (GMT) Received: from [192.168.2.119] (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with ESMTP id 5241016DD99; Tue, 8 Jun 2004 09:53:18 +0000 (GMT) Message-ID: <40C58CA2.4090107@outblaze.com> Date: Tue, 08 Jun 2004 17:53:38 +0800 From: Christopher Chan User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Feldman Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.2-5; VAE: 6.25.0.61; VDF: 6.25.0.87; host: corpmail.outblaze.com) X-archive-position: 5742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 758 Lines: 19 Scott Feldman wrote: > I see no reason to keep the non-NAPI option for e100. This patch removes > the CONFIG_E100_NAPI option and puts the driver in NAPI mode all the time. > Matches the way tg3 works. > > Unless someone has a really good reason to keep the non-NAPI mode, this > should go in for 2.6.7. I for one need to test 2.6.6 e100 with NAPI on. Under 2.6.3/4 I had problems with NAPI mode turned on. Turning NAPI off and then also doing net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.route.gc_thresh = 65536 net.ipv4.route.max_size = 1048576 was the only way to keep the machines I run available via the network. I would get dst cache overflows and sometimes the kernel will log garbled messages and when that happens the box requires a reboot. From fYxyjXcsJSNVtt@party.seed.net.tw Tue Jun 8 03:41:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 03:41:39 -0700 (PDT) Received: from usre-2s3z81m5xn (usre52@[218.107.199.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58AfSgi009069 for ; Tue, 8 Jun 2004 03:41:34 -0700 Date: Tue, 8 Jun 2004 03:41:28 -0700 Received: from mail by giga.net.tw with SMTP id 7VM7kPs0AHwVL01L4DLnIg; Tue, 08 Jun 2004 18:48:36 +0800 Message-ID: From: qiaoxiaol@126.com To: DMailer@oss.sgi.com Subject: flexible printed circuits supplier X-Mailer: 7LFZ3yh76vMageW Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id i58AfSgi009069 X-archive-position: 5743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: qiaoxiaol@126.com Precedence: bulk X-list: netdev Content-Length: 1192 Lines: 41 Dear sir, Wish you have good business! We are glad to introduce a flexible printed circuit (FPC) factory. we use the latest technology make flexible printed circuits (FPC) for use in any electronic products.The FACTURE is ISO9001:2000, and confirmed to IPC criteria. THE MAIN CAPACITY: 1,CAN MAKE DOUBLE SIDED WITH MIN 0.06MM TRACE WIDTH. THE SQUARE HOLE OF THE COVERLAYER CAN BE MIN 0.4 MM. 2,CAN MAKE 3 LAYERS,4 LAYERS,5 LAYERS,6 LAYERS FPC. 3,PRODUCTS HAVE EXPORTED TO USA,CANADA,JAPAN,UK,GERMANY,FRANCE,AUSTRALIA ETC MORE THEN 20 COUNTRIES. 4,MAIN CUSTOMER ARE NOKIA,PANASONIC,SONY,DELL,TDK ,PHILIP ETC. We would welcome you to visit our factory. Please e-mail your circuit design by Gerber file, Auto Cad, protel files and advise us of: FPC size, and number of layers. We can make samples for your approval, with factory direct pricing. If you donot want us to send you again, you can use the latest outlook2003 soft,to enter this e-mail address as reject e-mail address.you can solve all the worry. Or send an email with: " Remove" in the subject .we'll delete it from our list. hank you for your support! Best regards! Bai zhan yuan qiaoxiaol@126.com From herbert@gondor.apana.org.au Tue Jun 8 04:19:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 04:19:45 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58BJbgi016253 for ; Tue, 8 Jun 2004 04:19: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 1BXede-00073D-00; Tue, 08 Jun 2004 21:19:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BXedb-00076X-00; Tue, 08 Jun 2004 21:19:27 +1000 From: Herbert Xu To: scott.feldman@intel.com (Feldman, Scott) Subject: Re: [RFC] Wireless extensions rethink Cc: 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.25-1-686-smp (i686)) Message-Id: Date: Tue, 08 Jun 2004 21:19:27 +1000 X-archive-position: 5745 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: 328 Lines: 10 Feldman, Scott wrote: > > 9) [Open] What to do about wireless events? Any ideas? netlink -- 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 Adam.Lewis@motorola.com Mon Jun 7 22:12:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 04:22:33 -0700 (PDT) Received: from motgate6.mot.com (motgate6.mot.com [144.189.100.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i585Bwgi012935 for ; Mon, 7 Jun 2004 22:12:01 -0700 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i57L0epc015302 for ; Mon, 7 Jun 2004 14:00:40 -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 i57KxHlG030422 for ; Mon, 7 Jun 2004 15:59:17 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 16:00:39 -0500 Message-ID: From: Lewis Adam-CAL022 To: netdev@oss.sgi.com Subject: Linux Oops on skb_release_data() Date: Mon, 7 Jun 2004 16:00:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C44CD2.79F58ACE" X-archive-position: 5746 X-Approved-By: ralf@linux-mips.org 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: 8737 Lines: 133 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C44CD2.79F58ACE Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44CD2.79F58ACE" ------_=_NextPart_001_01C44CD2.79F58ACE Content-Type: text/plain; charset="ISO-8859-1" Hi, I've written a WLAN driver that I am trying to debug now. The problem occurs when I send lots of pings, really fast and force the driver to fragment the L3 and above payload. It will always oops after about 400 pings or so. When I run the oops through ksymoops, it always points me to skb_release_data(), ultimately the last thing it shows is __free_pages+c/50. I originally thought it was one of my calls to dev_free_skb() on the TX side, but I have since stubbed those out one-by-one to the point where I never call it in my code. Hence I must believe that it is Linux that is calling it after I pass data up via netif_rx(). My first guess is that the RF on the WLAN might be passing me garbage, so I hard coded some sanity checks in (this is easy since I'm only doing ARP and ping). Still it crashes, so I am at a loss. It looks like what I am passing up to the upper layers is good. The only other variable I can point to is that it seems to do this more when in bridge mode (e.g. I tie eth0 and wlan0 together). When I do this from wlan0 to wlan0 on (on two stations) it seems to not occur. Any ideas? Thanks, Adam ------_=_NextPart_001_01C44CD2.79F58ACE Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSI+DQo8VElUTEU+R2xhY2llcjwvVElU TEU+DQoNCjxTVFlMRT5CT0RZIHsNCglNQVJHSU4tVE9QOiAyMHB4OyBGT05ULVNJWkU6IDEwcHQ7 IE1BUkdJTi1MRUZUOiA1MHB4OyBDT0xPUjogIzAwNjY2NjsgRk9OVC1GQU1JTFk6IEFyaWFsLCBI ZWx2ZXRpY2ENCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAu MTQwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmFja2dyb3VuZD1jaWQ6MDIzMjY1 MzIwQDA3MDYyMDA0LTM3MjY+DQo8RElWPjxTUEFOIGNsYXNzPTAyMzI2NTMyMC0wNzA2MjAwND5I aSw8L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTAyMzI2NTMyMC0wNzA2MjAwND48L1NQ QU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTAyMzI2NTMyMC0wNzA2MjAwND5JJ3Zl IHdyaXR0ZW4gYSBXTEFOIGRyaXZlciB0aGF0IEkgYW0gdHJ5aW5nIA0KdG8gZGVidWcgbm93LiZu YnNwOyBUaGUgcHJvYmxlbSBvY2N1cnMgd2hlbiBJIHNlbmQgbG90cyBvZiBwaW5ncywgcmVhbGx5 IGZhc3QgDQphbmQgZm9yY2UgdGhlIGRyaXZlciB0byBmcmFnbWVudCB0aGUgTDMgYW5kIGFib3Zl IHBheWxvYWQuJm5ic3A7IEl0IHdpbGwgYWx3YXlzIA0Kb29wcyBhZnRlciBhYm91dCA0MDAgcGlu Z3Mgb3Igc28uJm5ic3A7IFdoZW4gSSBydW4gdGhlIG9vcHMgdGhyb3VnaCBrc3ltb29wcywgaXQg DQphbHdheXMgcG9pbnRzIG1lIHRvIHNrYl9yZWxlYXNlX2RhdGEoKSwgdWx0aW1hdGVseSB0aGUg bGFzdCB0aGluZyBpdCBzaG93cyBpcyANCl9fZnJlZV9wYWdlcytjLzUwLjwvU1BBTj48L0RJVj4N CjxESVY+PFNQQU4gY2xhc3M9MDIzMjY1MzIwLTA3MDYyMDA0PjwvU1BBTj4mbmJzcDs8L0RJVj4N CjxESVY+PFNQQU4gY2xhc3M9MDIzMjY1MzIwLTA3MDYyMDA0Pkkgb3JpZ2luYWxseSB0aG91Z2h0 IGl0IHdhcyBvbmUgb2YgbXkgY2FsbHMgDQp0byBkZXZfZnJlZV9za2IoKSBvbiB0aGUgVFggc2lk ZSwgYnV0IEkgaGF2ZSBzaW5jZSBzdHViYmVkIHRob3NlIG91dCBvbmUtYnktb25lIA0KdG8gdGhl IHBvaW50IHdoZXJlIEkgbmV2ZXIgY2FsbCBpdCBpbiBteSBjb2RlLiZuYnNwOyBIZW5jZSBJIG11 c3QgYmVsaWV2ZSB0aGF0IA0KaXQgaXMgTGludXggdGhhdCBpcyBjYWxsaW5nIGl0IGFmdGVyIEkg cGFzcyBkYXRhIHVwIHZpYSBuZXRpZl9yeCgpLiZuYnNwOyANCjwvU1BBTj48L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9MDIzMjY1MzIwLTA3MDYyMDA0PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9MDIzMjY1MzIwLTA3MDYyMDA0Pk15IGZpcnN0IGd1ZXNzIGlzIHRoYXQgdGhl IFJGIG9uIHRoZSBXTEFOIA0KbWlnaHQgYmUgcGFzc2luZyBtZSBnYXJiYWdlLCBzbyBJIGhhcmQg Y29kZWQgc29tZSBzYW5pdHkgY2hlY2tzIGluICh0aGlzIGlzIGVhc3kgDQpzaW5jZSBJJ20gb25s eSBkb2luZyBBUlAgYW5kIHBpbmcpLiZuYnNwOyBTdGlsbCBpdCBjcmFzaGVzLCBzbyBJIGFtIGF0 IGEgDQpsb3NzLiZuYnNwOyBJdCBsb29rcyBsaWtlIHdoYXQgSSBhbSBwYXNzaW5nIHVwIHRvIHRo ZSB1cHBlciBsYXllcnMgaXMgDQpnb29kLiZuYnNwOyBUaGUgb25seSBvdGhlciB2YXJpYWJsZSBJ IGNhbiBwb2ludCB0byBpcyB0aGF0IGl0IHNlZW1zIHRvIGRvIHRoaXMgDQptb3JlIHdoZW4gaW4g YnJpZGdlIG1vZGUgKGUuZy4gSSB0aWUgZXRoMCBhbmQgd2xhbjAgdG9nZXRoZXIpLiZuYnNwOyBX aGVuIEkgZG8gDQp0aGlzIGZyb20gd2xhbjAgdG8gd2xhbjAgb24gKG9uIHR3byBzdGF0aW9ucykg aXQgc2VlbXMgdG8gbm90IG9jY3VyLiZuYnNwOyANCjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MDIzMjY1MzIwLTA3MDYyMDA0PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MDIzMjY1MzIwLTA3MDYyMDA0PkFueSBpZGVhcz88L1NQQU4+PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTAyMzI2NTMyMC0wNzA2MjAwND48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTAyMzI2NTMyMC0wNzA2MjAwND5UaGFua3MsPC9TUEFOPjwvRElWPg0KPERJVj48 U1BBTiBjbGFzcz0wMjMyNjUzMjAtMDcwNjIwMDQ+QWRhbTwvU1BBTj48L0RJVj48L0JPRFk+PC9I VE1MPg0K ------_=_NextPart_001_01C44CD2.79F58ACE-- ------_=_NextPart_000_01C44CD2.79F58ACE Content-Type: image/jpeg; name="Glacier Bkgrd.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Glacier Bkgrd.jpg" Content-ID: <023265320@07062004-3726> /9j/4AAQSkZJRgABAgEASABIAAD/7QSqUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAAC2gIo/+H/4QL5AkUDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC QAAAAAA4QklNBAkAAAAAApkAAAABAAAAgAAAAAEAAAGAAAABgAAAAn0AGAAB/9j/4AAQSkZJRgAB AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAEAgAMBIgACEQEDEQH/3QAEAAj/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APTqPon4/wAAir5X SQGyn6oSXyukip+qEl8rpJKfqhJfK6SSn6oSXyukkp+qEl8rpJKfqhJfK6SSn6oSXyukkp//2QA4 QklNBAYAAAAAAAcABAAAAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGQAAAAAAf/bAIQABgQEBwUHCwYGCw4KCAoOEQ4ODg4RFhMTExMTFhEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEHCQkTDBMiExMiFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAAwZAAwERAAIRAQMR Af/dAAQAyP/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE 1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp 0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo +DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A9N/vv+Lv+SWFhv5/7F37 7/i7/kliu/n/ALFbJ63H/dv0+lTFd/P/AGKj++/y/wDkliu/n/sVa29Tl8fSn7fCn/JPfFIRH/AY GTv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd /wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFX f8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gM Vd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+ AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8A gMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/ 4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq 7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wAB irv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq/wD/2Q== ------_=_NextPart_000_01C44CD2.79F58ACE-- From hadi@cyberus.ca Tue Jun 8 04:29:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 04:29:27 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58BTMgi017075 for ; Tue, 8 Jun 2004 04:29:22 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BXen8-0005qy-St for netdev@oss.sgi.com; Tue, 08 Jun 2004 07:29:18 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BXen5-0000eo-Gm; Tue, 08 Jun 2004 07:29:15 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Andi Kleen In-Reply-To: <200406080841.14579.vkondra@mail.ru> References: <200406062128.47070.vkondra@mail.ru> <200406072335.04125.vkondra@mail.ru> <1086651524.1037.10.camel@jzny.localdomain> <200406080841.14579.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086694124.1039.44.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jun 2004 07:28:44 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5747 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: 1861 Lines: 40 On Tue, 2004-06-08 at 01:41, Vladimir Kondratiev wrote: > > DMA rings or channles on the NIC? Could you not use a tag like fwmark to > > select DMA to send to? > > Explain the packet path once it hits the driver. > > Let's put aside integrated service. For diff serv, > NIC have 4 DMA queues. These 4 queues acts as 4 independent 802.11 channels > with different backoff and contention window parameters. Actually, it is > dictated by TGe, and should be common for wireless stack. Queue consumption > depends on conditions on air and access point settings. Access point set > these different parameters for queues, and may change it time to time. Ok, Now that you explain this i dont think other people understood you when you started talking about qos. We have discussed this topic on netdev before under differnt context. So the 4 DMA queues are infact different QoS levels? Another way to use multiple tx DMA channels is to parallelize sending. Are there multiple receive channels as well? BTW, what is TGe? The only obstacle i see at the moment in the architecture is we stop the transmit path if a DMA ring is full. That is making assumption there is only one DMA path. To work around this you could have 4 independent virtual netdevices on top of the real physical device - something like a tamed down bonding driver; this is not a very good abstraction because there is only one physical MAC. Another scheme is to mark the fwmark or priority with the right DMA path selection. Once it gets to the driver you try to send to the correct ring and if thats full, you go to the next lower priority ring etc and when theres no more DMA paths left you drop. The disadvantage with such a scheme is complexity in keeping track of busy DMA paths. I am trying to think of a clean way - maybe i need to get some caffeine first. Jeff? Andi? cheers, jamal From hadi@cyberus.ca Tue Jun 8 05:30:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 05:30:54 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58CUogi019150 for ; Tue, 8 Jun 2004 05:30:50 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BXfkc-0004xW-V0 for netdev@oss.sgi.com; Tue, 08 Jun 2004 08:30:46 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BXfkZ-0001sp-Hd; Tue, 08 Jun 2004 08:30:43 -0400 Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time (fwd) From: jamal Reply-To: hadi@cyberus.ca To: Marc Herbert Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1086697812.1035.60.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jun 2004 08:30:12 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5748 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: 1019 Lines: 28 On Tue, 2004-06-08 at 04:50, Marc Herbert wrote: > On Fri, 4 Jun 2004, Scott Feldman wrote: > > > I see no reason to keep the non-NAPI option for e100. This patch removes > > the CONFIG_E100_NAPI option and puts the driver in NAPI mode all the time. > > Matches the way tg3 works. > > > > Unless someone has a really good reason to keep the non-NAPI mode, this > > should go in for 2.6.7. > > Scott, > > If I understand pre-NAPI history correctly (please anyone correct > me), the rationale/reason for the old, "backlog" SW FIFO design was to > cope with network bursts in the following context: > > (1) transient network throughput higher than what the CPU could > manage > (2) number of RxDescriptors (i.e., FIFO available to the NIC) too > small to cope with this burst on the NIC. The idea with the backlog queue is to defer work i.e the concept being a very little time time spent in high priority portions (such as inteupts. So nothing to do with any of the above as far as i know. cheers, jamal From P@draigBrady.com Tue Jun 8 05:34:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 05:35:00 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58CYvgi019521 for ; Tue, 8 Jun 2004 05:34:58 -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 i58CYqaq066586; Tue, 8 Jun 2004 13:34:53 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40C5B26C.7030305@draigBrady.com> Date: Tue, 08 Jun 2004 13:34:52 +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: Chris Carpinello CC: netdev@oss.sgi.com Subject: Re: e1000 w/ NAPI + SMP = 99% CPU utilization References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i58CYqaq066586 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i58CYvgi019521 X-archive-position: 5749 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: 1048 Lines: 28 Chris Carpinello wrote: > With a stock 2.6.5 kernel, I'm building the e1000 driver as a module > w/ NAPI turned on for an SMP host (Dell PowerEdge 1650 with 4 1Gb > Intel NICs). ksoftirqd/0 is using 99% CPU utilization. However, when > I recompile the kernel with NAPI turned off, ksoftirqd/0 behaves > normally. Likewise, when I leave NAPI configured but turn off SMP > support, ksoftirqd is fine. The system in question has 2x Intel > Corp. 82544EI (rev 02) and 2x Intel Corp. 82543GC (rev 02). > > I'm willing to test patches. Please CC me on responses, as I'm not > subscribed. Thanks. At what packet rate does it go to 100%? Anyway it's not much to worry about as it's in polling mode. One thing which should help is to share the work across your CPUs. `cat /proc/interrupts` will show the interrupts for your nics. Then you can bind the interrupt to a particular CPU like: echo 1 > /proc/irq/$num/smp_affinity echo 2 > /proc/irq/$num/smp_affinity echo 4 > /proc/irq/$num/smp_affinity echo 8 > /proc/irq/$num/smp_affinity Pdraig. From ak@suse.de Tue Jun 8 05:53:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 05:53:42 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58Crdgi020154 for ; Tue, 8 Jun 2004 05:53: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 D46466B4073; Tue, 8 Jun 2004 14:53:33 +0200 (CEST) Date: Tue, 8 Jun 2004 14:53:33 +0200 From: Andi Kleen To: Lewis Adam-CAL022 Cc: netdev@oss.sgi.com Subject: Re: Linux Oops on skb_release_data() Message-ID: <20040608125333.GA1271@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5750 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: 230 Lines: 7 > Any ideas? Most likely you're corrupting memory somewhere, in particular overwrite the boundaries of the your skb data area. I would suggest to build the kernel with slab debugging and check all your skb->data accesses. -Andi From mcgrof@studorgs.rutgers.edu Tue Jun 8 07:53:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 07:53:37 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58ErWgi027050 for ; Tue, 8 Jun 2004 07:53:32 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id D5287F9D4D; Tue, 8 Jun 2004 10:53:31 -0400 (EDT) Date: Tue, 8 Jun 2004 10:53:31 -0400 To: Netdev , prism54-devel@prism54.org Subject: Prism54 patches Message-ID: <20040608145331.GL895@ruslug.rutgers.edu> Mail-Followup-To: Netdev , prism54-devel@prism54.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 5751 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: 228 Lines: 10 Jeff, what's the status of the prism54 patches. I'd like to know so that if there is anything you or others don't like we fix immediately. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From linux_lover2004@yahoo.com Tue Jun 8 08:44:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 08:44:43 -0700 (PDT) Received: from web52208.mail.yahoo.com (web52208.mail.yahoo.com [206.190.39.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58Fiegi031894 for ; Tue, 8 Jun 2004 08:44:40 -0700 Message-ID: <20040608154412.14868.qmail@web52208.mail.yahoo.com> Received: from [61.11.18.134] by web52208.mail.yahoo.com via HTTP; Tue, 08 Jun 2004 08:44:12 PDT Date: Tue, 8 Jun 2004 08:44:12 -0700 (PDT) From: linux lover Subject: how to interpret C statement? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-321018539-1086709452=:14820" X-archive-position: 5752 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: 1049 Lines: 28 --0-321018539-1086709452=:14820 Content-Type: text/plain; charset=us-ascii how to interpret following C statement? #define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0])) what is use of tcp_skb_cb structure in kernel source tcp.h? how TCP_SKB_CB(skb) is translated in its definition? regards, linux_lover --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger --0-321018539-1086709452=:14820 Content-Type: text/html; charset=us-ascii
how to interpret following C statement?
#define TCP_SKB_CB(__skb)       ((struct tcp_skb_cb *)&((__skb)->cb[0]))
what is use of tcp_skb_cb structure in kernel source tcp.h? how TCP_SKB_CB(skb) is translated in its definition?
regards,
linux_lover

Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger --0-321018539-1086709452=:14820-- From rl@hellgate.ch Tue Jun 8 08:59:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 08:59:09 -0700 (PDT) Received: from mail3.bluewin.ch (mail3.bluewin.ch [195.186.1.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58Fx6gi000342 for ; Tue, 8 Jun 2004 08:59:06 -0700 Received: from k3.hellgate.ch (83.77.123.217) by mail3.bluewin.ch (Bluewin AG 7.0.028) id 40A4696300311130; Mon, 7 Jun 2004 21:28:06 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 8141D6B2EAF; Mon, 7 Jun 2004 23:28:04 +0200 (CEST) Date: Mon, 7 Jun 2004 23:28:04 +0200 From: Roger Luethi To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [RFC] ethtool semantics Message-ID: <20040607212804.GA17012@k3.hellgate.ch> Mail-Followup-To: "David S. Miller" , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 508 Lines: 16 What is the correct response if a user passes ethtool speed or duplex arguments while autoneg is on? Some possible answers are: a) Yell at the user for doing something stupid. b) Fail silently (i.e. ignore command). c) Change advertised value accordingly and initiate new negotiation. d) Consider "autoneg off" implied, force media accordingly. The ethtool(8) man page I'm looking at doesn't address that question. The actual behavior I've seen is b) which is by far my least preferred solution. Roger From jt@bougret.hpl.hp.com Tue Jun 8 09:58:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 09:58:17 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58GwDgi002555 for ; Tue, 8 Jun 2004 09:58:14 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 885BD1C1139D; Tue, 8 Jun 2004 09:58:13 -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 JAA23170; Tue, 8 Jun 2004 09:59:22 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BXjvQ-0004Jw-00; Tue, 08 Jun 2004 09:58:12 -0700 Date: Tue, 8 Jun 2004 09:58:12 -0700 To: "Andonieh, Joe" Cc: netdev@oss.sgi.com, Jouni Malinen Subject: Re: RFC: Linux wireless extensions and WPA support Message-ID: <20040608165812.GA16595@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <386CBF9421521B41835E2BF21BEF80B8919069@hasmsx402.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <386CBF9421521B41835E2BF21BEF80B8919069@hasmsx402.ger.corp.intel.com> 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: 5755 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: 1172 Lines: 42 On Tue, Jun 08, 2004 at 10:36:25AM +0300, Andonieh, Joe wrote: > #define IW_AUTH_WPA_VERSION 0 > --- > #define IW_AUTH_WPA_VERSION_DISABLED 0 > #define IW_AUTH_WPA_VERSION_WPA 1 > #define IW_AUTH_WPA_VERSION_WPA2 2 > --- > #define IW_AUTH_CIPHER_PAIRWISE 1 > #define IW_AUTH_CIPHER_GROUP 2 > --- > #define IW_AUTH_CIPHER_NONE 0 > #define IW_AUTH_CIPHER_WEP40 1 > #define IW_AUTH_CIPHER_TKIP 2 > #define IW_AUTH_CIPHER_CCMP 4 > #define IW_AUTH_CIPHER_WEP104 5 > > I wonder how this definition let you differentiate between the unicast > cipher and the group cipher? Yes : PAIRWISE vs. GROUP. > Moreover there is two information that are > needed > > 1) the authentication model, which is PSK or .1x > 2) The cipher to connect with? > Shall we set both Pair wise and Group or only Pairwise and > connect with what ever group cipher in the RSN IE -- hint this will > enable smooth connection to mixed mode networks? Those things are in Jouni's original proposal, and I don't intend to drop them. I quoted only a small snipset, to clarify, please refer to his e-mail to get the full picture. > Please let me know what you think? > > Thanks > Joe Regards, Jean From shemminger@osdl.org Tue Jun 8 11:05:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:06:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58I5vgi004939 for ; Tue, 8 Jun 2004 11:05:58 -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 i58I4Kr00361; Tue, 8 Jun 2004 11:04:20 -0700 Date: Tue, 8 Jun 2004 11:04:20 -0700 From: Stephen Hemminger To: "Venkatesan, Ganesh" Cc: "cramerj" , "Ronciak, John" , "Jeff Garzik" , netdev@oss.sgi.com Subject: [PATCH] e1000 module parameter incompatiablity Message-Id: <20040608110420.3b93338d@dell_ss3.pdx.osdl.net> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> 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: 5758 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: 799 Lines: 22 E1000 driver is mixing new style 'module_param' with old style 'MODULE_PARM' this generates the runtime warning e1000: Ignoring new-style parameters in presence of obsolete ones and prevents using module parameters to set ring size. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2004-06-08 11:01:58 -07:00 +++ b/drivers/net/e1000/e1000_main.c 2004-06-08 11:01:58 -07:00 @@ -202,8 +202,8 @@ MODULE_DESCRIPTION("Intel(R) PRO/1000 Network Driver"); MODULE_LICENSE("GPL"); -static int debug = 3; -module_param(debug, int, 0); +static int debug = NETIF_MSG_DRV | NETIF_MSG_PROBE; +MODULE_PARM(debug, "i"); MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); /** From chriscarpinello@hotmail.com Tue Jun 8 11:14:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:14:26 -0700 (PDT) Received: from hotmail.com (bay1-f139.bay1.hotmail.com [65.54.245.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58IEMgi005380 for ; Tue, 8 Jun 2004 11:14:22 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Jun 2004 11:14:18 -0700 Received: from 209.182.184.2 by by1fd.bay1.hotmail.msn.com with HTTP; Tue, 08 Jun 2004 18:14:17 GMT X-Originating-IP: [209.182.184.2] X-Originating-Email: [chriscarpinello@hotmail.com] X-Sender: chriscarpinello@hotmail.com From: "Chris Carpinello" To: P@draigBrady.com Cc: netdev@oss.sgi.com Subject: Re: e1000 w/ NAPI + SMP = 99% CPU utilization Date: Tue, 08 Jun 2004 14:14:17 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jun 2004 18:14:18.0268 (UTC) FILETIME=[6A00DDC0:01C44D84] X-archive-position: 5759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chriscarpinello@hotmail.com Precedence: bulk X-list: netdev Content-Length: 2538 Lines: 75 >Padraig wrote: >At what packet rate does it go to 100%? I haven't narrowed down a threshold. tcpstat reports bps=202737465 on eth3. eth0 is a management interface (doesn't packet sniff). eth1 and eth2 are ifconfig'd down. >Anyway it's not much to worry about as >it's in polling mode. I'm concerned because when I ifconfig down eth3 the kernel panics. Under high traffic loads, the box will panic as well. Here's the oops, which is hand copied from the console: Oops: 0002 [#1] SMP CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010002 (2.6.5) EIP is at net_rx_action+0x86/0x120 eax: 00200200 ebx: df22b0fc ecx: 0000009d edx: 00100100 esi: df22b000 edi: c1508840 ebp: fffe4c97 esp: dff8bf78 ds: 007b es: 007b ss: 0068 Process ksoftirqd/0 (pid: 3, threadinfo=dff8a000 task=dff90600) Stack: df22b000 df8bf80 000000ec 00000001 c04f1c18 0000000a 00000246 c0126a7a c04f1c18 dff8a000 dff8a000 dff8a000 c0126f10 c0126f95 dff90600 00000013 dff8a000 dff93f74 00000000 c01367aa 00000000 00000003 00000000 fffffffc Call Trace: [] do_softirq+0xca/0xd0 [] ksoftirqd+0x0/0xd0 [] ksoftirqd+0x85/0xd0 [] kthread+0xba/0xc0 [] kthread+0x0/0xc0 [] kernel_thread_helper+0x5/0x10 Code: 89 42 04 89 10 8d 57 1c c7 43 04 00 02 20 00 8b 42 04 89 13 <0> Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing >One thing which should help is to share >the work across your CPUs. `cat /proc/interrupts` >will show the interrupts for your nics. # cat /proc/interrupts CPU0 CPU1 0: 3758655 3223347 IO-APIC-edge timer 1: 2 7 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 14: 22 7 IO-APIC-edge ide0 16: 11 11 IO-APIC-level eth1 17: 5471 5475 IO-APIC-level eth0 18: 1790 1794 IO-APIC-level aic7xxx 19: 15 15 IO-APIC-level aic7xxx 20: 2 1 IO-APIC-level eth2 24: 1549 1349 IO-APIC-level eth3 NMI: 0 0 LOC: 6982002 6982001 ERR: 0 MIS: 0 >Then you can bind the interrupt to a particular CPU like: > >echo 1 > /proc/irq/$num/smp_affinity >echo 2 > /proc/irq/$num/smp_affinity >echo 4 > /proc/irq/$num/smp_affinity >echo 8 > /proc/irq/$num/smp_affinity Setting the mask has no noticeable effect on ksoftirqd's behavior. - Chris From jgarzik@pobox.com Tue Jun 8 11:30:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:30:11 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58IU6gi006055 for ; Tue, 8 Jun 2004 11:30:07 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlML-0006RX-BY; Tue, 08 Jun 2004 19:30:05 +0100 Message-ID: <40C605A1.2000402@pobox.com> Date: Tue, 08 Jun 2004 14:29:53 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Cox CC: linux-kernel@vger.kernel.org, Netdev Subject: Re: PATCH: epic100 fixes References: <20040607155334.GA10637@devserv.devel.redhat.com> In-Reply-To: <20040607155334.GA10637@devserv.devel.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5761 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: 43 Lines: 2 Applied to 2.6, will apply to 2.4 soonish From jgarzik@pobox.com Tue Jun 8 11:29:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:29:43 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58ITYgi005929 for ; Tue, 8 Jun 2004 11:29:35 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlLp-0006RJ-64; Tue, 08 Jun 2004 19:29:33 +0100 Message-ID: <40C6057F.9060509@pobox.com> Date: Tue, 08 Jun 2004 14:29:19 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Cox CC: linux-kernel@vger.kernel.org, akpm@osdl.org, "David S. Miller" , Netdev Subject: Re: PATCH: ethtool power manglement hooks References: <20040607155018.GA5810@devserv.devel.redhat.com> In-Reply-To: <20040607155018.GA5810@devserv.devel.redhat.com> Content-Type: multipart/mixed; boundary="------------010305080009080309070609" X-archive-position: 5760 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: 16375 Lines: 566 This is a multi-part message in MIME format. --------------010305080009080309070609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit applied to 2.6 verbatim, applied to 2.4 slightly modified (2.4 patch attached, and DaveM CC added). --------------010305080009080309070609 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/08 14:27:21-04:00 jgarzik@pobox.com # [netdrvr] fix ethtool_ops design bug, sync with 2.6.x ethtool_ops code # # In addition to merging Alan Cox's fix for an ethtool_ops design bug, # I took the opportunity to synchronize the source with 2.6.x, which # will make it easier to maintain in the long run. # # Description of the fix from Alan Cox : # # [PATCH] ethtool power manglement hooks # # Several ethernet drivers have been broken by the ethtool support because # the ioctl code used to power the interface up and down as needed. Rather # than add this to each driver call Jeff Garzik suggested we add hooks # for before/after ethtool processing. # # This patch implements them which makes fixing the PM stuff easier, # as the epic100 patch to follow will show. It also cleans up the # via-velocity driver pm/ethtool logic a great deal. As per Jeff's # request the before handler is allowed to fail the operation. # # -- # # The contribution herein included is a creation of Red Hat Inc. It is hereby # submitted under the license of the existing files and as a derivative work # thereof. I know of no reason for not having the right to submit the # work herein included. # # (Bluff your way in legalese ;)) # diff -Nru a/include/linux/ethtool.h b/include/linux/ethtool.h --- a/include/linux/ethtool.h 2004-06-08 14:27:33 -04:00 +++ b/include/linux/ethtool.h 2004-06-08 14:27:33 -04:00 @@ -345,6 +345,8 @@ int (*phys_id)(struct net_device *, u32); int (*get_stats_count)(struct net_device *); void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *); + int (*begin)(struct net_device *); + void (*complete)(struct net_device *); }; /* CMDs currently supported */ diff -Nru a/net/core/Makefile b/net/core/Makefile --- a/net/core/Makefile 2004-06-08 14:27:33 -04:00 +++ b/net/core/Makefile 2004-06-08 14:27:33 -04:00 @@ -9,7 +9,7 @@ O_TARGET := core.o -export-objs := netfilter.o profile.o +export-objs := netfilter.o profile.o ethtool.o obj-y := sock.o skbuff.o iovec.o datagram.o scm.o diff -Nru a/net/core/ethtool.c b/net/core/ethtool.c --- a/net/core/ethtool.c 2004-06-08 14:27:33 -04:00 +++ b/net/core/ethtool.c 2004-06-08 14:27:33 -04:00 @@ -9,6 +9,7 @@ * It's GPL, stupid. */ +#include #include #include #include @@ -56,9 +57,26 @@ return 0; } +#ifdef NETIF_F_TSO +u32 ethtool_op_get_tso(struct net_device *dev) +{ + return (dev->features & NETIF_F_TSO) != 0; +} + +int ethtool_op_set_tso(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_TSO; + else + dev->features &= ~NETIF_F_TSO; + + return 0; +} +#endif /* NETIF_F_TSO */ + /* Handlers for each ethtool command */ -static int ethtool_get_settings(struct net_device *dev, void *useraddr) +static int ethtool_get_settings(struct net_device *dev, void __user *useraddr) { struct ethtool_cmd cmd = { ETHTOOL_GSET }; int err; @@ -75,7 +93,7 @@ return 0; } -static int ethtool_set_settings(struct net_device *dev, void *useraddr) +static int ethtool_set_settings(struct net_device *dev, void __user *useraddr) { struct ethtool_cmd cmd; @@ -88,7 +106,7 @@ return dev->ethtool_ops->set_settings(dev, &cmd); } -static int ethtool_get_drvinfo(struct net_device *dev, void *useraddr) +static int ethtool_get_drvinfo(struct net_device *dev, void __user *useraddr) { struct ethtool_drvinfo info; struct ethtool_ops *ops = dev->ethtool_ops; @@ -114,7 +132,7 @@ return 0; } -static int ethtool_get_regs(struct net_device *dev, char *useraddr) +static int ethtool_get_regs(struct net_device *dev, char __user *useraddr) { struct ethtool_regs regs; struct ethtool_ops *ops = dev->ethtool_ops; @@ -150,7 +168,7 @@ return ret; } -static int ethtool_get_wol(struct net_device *dev, char *useraddr) +static int ethtool_get_wol(struct net_device *dev, char __user *useraddr) { struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; @@ -164,7 +182,7 @@ return 0; } -static int ethtool_set_wol(struct net_device *dev, char *useraddr) +static int ethtool_set_wol(struct net_device *dev, char __user *useraddr) { struct ethtool_wolinfo wol; @@ -177,7 +195,7 @@ return dev->ethtool_ops->set_wol(dev, &wol); } -static int ethtool_get_msglevel(struct net_device *dev, char *useraddr) +static int ethtool_get_msglevel(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata = { ETHTOOL_GMSGLVL }; @@ -191,7 +209,7 @@ return 0; } -static int ethtool_set_msglevel(struct net_device *dev, char *useraddr) +static int ethtool_set_msglevel(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata; @@ -213,7 +231,7 @@ return dev->ethtool_ops->nway_reset(dev); } -static int ethtool_get_link(struct net_device *dev, void *useraddr) +static int ethtool_get_link(struct net_device *dev, void __user *useraddr) { struct ethtool_value edata = { ETHTOOL_GLINK }; @@ -227,7 +245,7 @@ return 0; } -static int ethtool_get_eeprom(struct net_device *dev, void *useraddr) +static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr) { struct ethtool_eeprom eeprom; struct ethtool_ops *ops = dev->ethtool_ops; @@ -272,7 +290,7 @@ return ret; } -static int ethtool_set_eeprom(struct net_device *dev, void *useraddr) +static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr) { struct ethtool_eeprom eeprom; struct ethtool_ops *ops = dev->ethtool_ops; @@ -313,7 +331,7 @@ return ret; } -static int ethtool_get_coalesce(struct net_device *dev, void *useraddr) +static int ethtool_get_coalesce(struct net_device *dev, void __user *useraddr) { struct ethtool_coalesce coalesce = { ETHTOOL_GCOALESCE }; @@ -327,7 +345,7 @@ return 0; } -static int ethtool_set_coalesce(struct net_device *dev, void *useraddr) +static int ethtool_set_coalesce(struct net_device *dev, void __user *useraddr) { struct ethtool_coalesce coalesce; @@ -340,7 +358,7 @@ return dev->ethtool_ops->set_coalesce(dev, &coalesce); } -static int ethtool_get_ringparam(struct net_device *dev, void *useraddr) +static int ethtool_get_ringparam(struct net_device *dev, void __user *useraddr) { struct ethtool_ringparam ringparam = { ETHTOOL_GRINGPARAM }; @@ -354,7 +372,7 @@ return 0; } -static int ethtool_set_ringparam(struct net_device *dev, void *useraddr) +static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr) { struct ethtool_ringparam ringparam; @@ -367,7 +385,7 @@ return dev->ethtool_ops->set_ringparam(dev, &ringparam); } -static int ethtool_get_pauseparam(struct net_device *dev, void *useraddr) +static int ethtool_get_pauseparam(struct net_device *dev, void __user *useraddr) { struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM }; @@ -381,7 +399,7 @@ return 0; } -static int ethtool_set_pauseparam(struct net_device *dev, void *useraddr) +static int ethtool_set_pauseparam(struct net_device *dev, void __user *useraddr) { struct ethtool_pauseparam pauseparam; @@ -394,7 +412,7 @@ return dev->ethtool_ops->set_pauseparam(dev, &pauseparam); } -static int ethtool_get_rx_csum(struct net_device *dev, char *useraddr) +static int ethtool_get_rx_csum(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata = { ETHTOOL_GRXCSUM }; @@ -408,7 +426,7 @@ return 0; } -static int ethtool_set_rx_csum(struct net_device *dev, char *useraddr) +static int ethtool_set_rx_csum(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata; @@ -422,7 +440,7 @@ return 0; } -static int ethtool_get_tx_csum(struct net_device *dev, char *useraddr) +static int ethtool_get_tx_csum(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata = { ETHTOOL_GTXCSUM }; @@ -436,7 +454,7 @@ return 0; } -static int ethtool_set_tx_csum(struct net_device *dev, char *useraddr) +static int ethtool_set_tx_csum(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata; @@ -449,7 +467,7 @@ return dev->ethtool_ops->set_tx_csum(dev, edata.data); } -static int ethtool_get_sg(struct net_device *dev, char *useraddr) +static int ethtool_get_sg(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata = { ETHTOOL_GSG }; @@ -463,7 +481,7 @@ return 0; } -static int ethtool_set_sg(struct net_device *dev, char *useraddr) +static int ethtool_set_sg(struct net_device *dev, char __user *useraddr) { struct ethtool_value edata; @@ -476,7 +494,39 @@ return dev->ethtool_ops->set_sg(dev, edata.data); } -static int ethtool_self_test(struct net_device *dev, char *useraddr) +#ifdef NETIF_F_TSO +static int ethtool_get_tso(struct net_device *dev, char __user *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTSO }; + + if (!dev->ethtool_ops->get_tso) + return -EOPNOTSUPP; + + edata.data = dev->ethtool_ops->get_tso(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_tso(struct net_device *dev, char __user *useraddr) +{ + struct ethtool_value edata; + + if (!dev->ethtool_ops->set_tso) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->ethtool_ops->set_tso(dev, edata.data); +} + +EXPORT_SYMBOL(ethtool_op_get_tso); +EXPORT_SYMBOL(ethtool_op_set_tso); +#endif /* NETIF_F_TSO */ + +static int ethtool_self_test(struct net_device *dev, char __user *useraddr) { struct ethtool_test test; struct ethtool_ops *ops = dev->ethtool_ops; @@ -509,7 +559,7 @@ return ret; } -static int ethtool_get_strings(struct net_device *dev, void *useraddr) +static int ethtool_get_strings(struct net_device *dev, void __user *useraddr) { struct ethtool_gstrings gstrings; struct ethtool_ops *ops = dev->ethtool_ops; @@ -556,7 +606,7 @@ return ret; } -static int ethtool_phys_id(struct net_device *dev, void *useraddr) +static int ethtool_phys_id(struct net_device *dev, void __user *useraddr) { struct ethtool_value id; @@ -569,7 +619,7 @@ return dev->ethtool_ops->phys_id(dev, id.data); } -static int ethtool_get_stats(struct net_device *dev, void *useraddr) +static int ethtool_get_stats(struct net_device *dev, void __user *useraddr) { struct ethtool_stats stats; struct ethtool_ops *ops = dev->ethtool_ops; @@ -607,8 +657,9 @@ int dev_ethtool(struct ifreq *ifr) { struct net_device *dev = __dev_get_by_name(ifr->ifr_name); - void *useraddr = (void *) ifr->ifr_data; + void __user *useraddr = ifr->ifr_data; u32 ethcmd; + int rc; /* * XXX: This can be pushed down into the ethtool_* handlers that @@ -626,69 +677,121 @@ if (copy_from_user(ðcmd, useraddr, sizeof (ethcmd))) return -EFAULT; + if(dev->ethtool_ops->begin) + if ((rc = dev->ethtool_ops->begin(dev)) < 0) + return rc; + switch (ethcmd) { case ETHTOOL_GSET: - return ethtool_get_settings(dev, useraddr); + rc = ethtool_get_settings(dev, useraddr); + break; case ETHTOOL_SSET: - return ethtool_set_settings(dev, useraddr); + rc = ethtool_set_settings(dev, useraddr); + break; case ETHTOOL_GDRVINFO: - return ethtool_get_drvinfo(dev, useraddr); + rc = ethtool_get_drvinfo(dev, useraddr); + + break; case ETHTOOL_GREGS: - return ethtool_get_regs(dev, useraddr); + rc = ethtool_get_regs(dev, useraddr); + break; case ETHTOOL_GWOL: - return ethtool_get_wol(dev, useraddr); + rc = ethtool_get_wol(dev, useraddr); + break; case ETHTOOL_SWOL: - return ethtool_set_wol(dev, useraddr); + rc = ethtool_set_wol(dev, useraddr); + break; case ETHTOOL_GMSGLVL: - return ethtool_get_msglevel(dev, useraddr); + rc = ethtool_get_msglevel(dev, useraddr); + break; case ETHTOOL_SMSGLVL: - return ethtool_set_msglevel(dev, useraddr); + rc = ethtool_set_msglevel(dev, useraddr); + break; case ETHTOOL_NWAY_RST: - return ethtool_nway_reset(dev); + rc = ethtool_nway_reset(dev); + break; case ETHTOOL_GLINK: - return ethtool_get_link(dev, useraddr); + rc = ethtool_get_link(dev, useraddr); + break; case ETHTOOL_GEEPROM: - return ethtool_get_eeprom(dev, useraddr); + rc = ethtool_get_eeprom(dev, useraddr); + break; case ETHTOOL_SEEPROM: - return ethtool_set_eeprom(dev, useraddr); + rc = ethtool_set_eeprom(dev, useraddr); + break; case ETHTOOL_GCOALESCE: - return ethtool_get_coalesce(dev, useraddr); + rc = ethtool_get_coalesce(dev, useraddr); + break; case ETHTOOL_SCOALESCE: - return ethtool_set_coalesce(dev, useraddr); + rc = ethtool_set_coalesce(dev, useraddr); + break; case ETHTOOL_GRINGPARAM: - return ethtool_get_ringparam(dev, useraddr); + rc = ethtool_get_ringparam(dev, useraddr); + break; case ETHTOOL_SRINGPARAM: - return ethtool_set_ringparam(dev, useraddr); + rc = ethtool_set_ringparam(dev, useraddr); + break; case ETHTOOL_GPAUSEPARAM: - return ethtool_get_pauseparam(dev, useraddr); + rc = ethtool_get_pauseparam(dev, useraddr); + break; case ETHTOOL_SPAUSEPARAM: - return ethtool_set_pauseparam(dev, useraddr); + rc = ethtool_set_pauseparam(dev, useraddr); + break; case ETHTOOL_GRXCSUM: - return ethtool_get_rx_csum(dev, useraddr); + rc = ethtool_get_rx_csum(dev, useraddr); + break; case ETHTOOL_SRXCSUM: - return ethtool_set_rx_csum(dev, useraddr); + rc = ethtool_set_rx_csum(dev, useraddr); + break; case ETHTOOL_GTXCSUM: - return ethtool_get_tx_csum(dev, useraddr); + rc = ethtool_get_tx_csum(dev, useraddr); + break; case ETHTOOL_STXCSUM: - return ethtool_set_tx_csum(dev, useraddr); + rc = ethtool_set_tx_csum(dev, useraddr); + break; case ETHTOOL_GSG: - return ethtool_get_sg(dev, useraddr); + rc = ethtool_get_sg(dev, useraddr); + break; case ETHTOOL_SSG: - return ethtool_set_sg(dev, useraddr); + rc = ethtool_set_sg(dev, useraddr); + break; +#ifdef NETIF_F_TSO + case ETHTOOL_GTSO: + rc = ethtool_get_tso(dev, useraddr); + break; + case ETHTOOL_STSO: + rc = ethtool_set_tso(dev, useraddr); + break; +#endif /* NETIF_F_TSO */ case ETHTOOL_TEST: - return ethtool_self_test(dev, useraddr); + rc = ethtool_self_test(dev, useraddr); + break; case ETHTOOL_GSTRINGS: - return ethtool_get_strings(dev, useraddr); + rc = ethtool_get_strings(dev, useraddr); + break; case ETHTOOL_PHYS_ID: - return ethtool_phys_id(dev, useraddr); + rc = ethtool_phys_id(dev, useraddr); + break; case ETHTOOL_GSTATS: - return ethtool_get_stats(dev, useraddr); + rc = ethtool_get_stats(dev, useraddr); + break; default: - return -EOPNOTSUPP; + rc = -EOPNOTSUPP; } + + if(dev->ethtool_ops->complete) + dev->ethtool_ops->complete(dev); + return rc; ioctl: if (dev->do_ioctl) return dev->do_ioctl(dev, ifr, SIOCETHTOOL); return -EOPNOTSUPP; } + +EXPORT_SYMBOL(dev_ethtool); +EXPORT_SYMBOL(ethtool_op_get_link); +EXPORT_SYMBOL(ethtool_op_get_sg); +EXPORT_SYMBOL(ethtool_op_get_tx_csum); +EXPORT_SYMBOL(ethtool_op_set_sg); +EXPORT_SYMBOL(ethtool_op_set_tx_csum); diff -Nru a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c 2004-06-08 14:27:33 -04:00 +++ b/net/netsyms.c 2004-06-08 14:27:33 -04:00 @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include @@ -621,12 +620,5 @@ EXPORT_SYMBOL(iw_handler_get_thrspy); EXPORT_SYMBOL(wireless_spy_update); #endif /* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */ - -/* ethtool.c */ -EXPORT_SYMBOL(ethtool_op_get_link); -EXPORT_SYMBOL(ethtool_op_get_tx_csum); -EXPORT_SYMBOL(ethtool_op_set_tx_csum); -EXPORT_SYMBOL(ethtool_op_get_sg); -EXPORT_SYMBOL(ethtool_op_set_sg); #endif /* CONFIG_NET */ --------------010305080009080309070609-- From jgarzik@pobox.com Tue Jun 8 11:31:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11: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.12.10/8.12.9) with SMTP id i58IVcgi006594 for ; Tue, 8 Jun 2004 11:31:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlNo-0006So-Mm; Tue, 08 Jun 2004 19:31:36 +0100 Message-ID: <40C605FC.3020907@pobox.com> Date: Tue, 08 Jun 2004 14:31:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: Gary N Spiess , netdev@oss.sgi.com Subject: Re: [PATCH] natsemi update 1/4 Use assigned MAC address References: <200406041451590078.0BC23855@136.179.85.112> <40C31C71.6000101@colorfullife.com> In-Reply-To: <40C31C71.6000101@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5762 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: 136 Lines: 5 Manfred, since there was discussion and multiple patches flying about, could you resend the patchset, now that the dust has settled? From jgarzik@pobox.com Tue Jun 8 11:33:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:33: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.12.10/8.12.9) with SMTP id i58IXEgi006927 for ; Tue, 8 Jun 2004 11:33:15 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlPM-0006Tz-HN; Tue, 08 Jun 2004 19:33:12 +0100 Message-ID: <40C6065C.8030907@pobox.com> Date: Tue, 08 Jun 2004 14:33:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: [NETDRV] Fix netdev leak on probe failure in 3c527 References: <20040605075515.GA28723@gondor.apana.org.au> In-Reply-To: <20040605075515.GA28723@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5763 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 applied From jgarzik@pobox.com Tue Jun 8 11:33:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:33: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.12.10/8.12.9) with SMTP id i58IXJgi006954 for ; Tue, 8 Jun 2004 11:33:20 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlPS-0006U1-84; Tue, 08 Jun 2004 19:33:18 +0100 Message-ID: <40C60662.9070008@pobox.com> Date: Tue, 08 Jun 2004 14:33:06 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: [NETDRV] Fixed MCA resource bugs in at1700 References: <20040605083834.GA29142@gondor.apana.org.au> In-Reply-To: <20040605083834.GA29142@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5764 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 applied From jgarzik@pobox.com Tue Jun 8 11:37:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:37: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.12.10/8.12.9) with SMTP id i58IbCgi007615 for ; Tue, 8 Jun 2004 11:37:13 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlTD-0006Y3-MS; Tue, 08 Jun 2004 19:37:11 +0100 Message-ID: <40C6074C.8000005@pobox.com> Date: Tue, 08 Jun 2004 14:37:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jesse Brandeburg CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.5] e1000: fix napi crash on ifdown during traffic References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5765 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 applied From jgarzik@pobox.com Tue Jun 8 11:39:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:39: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.12.10/8.12.9) with SMTP id i58IdYgi007972 for ; Tue, 8 Jun 2004 11:39:35 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlVV-0006aV-Kx; Tue, 08 Jun 2004 19:39:33 +0100 Message-ID: <40C607D9.5090506@pobox.com> Date: Tue, 08 Jun 2004 14:39:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: "Venkatesan, Ganesh" , cramerj , "Ronciak, John" , netdev@oss.sgi.com Subject: Re: [PATCH] e1000 module parameter incompatiablity References: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> <20040608110420.3b93338d@dell_ss3.pdx.osdl.net> In-Reply-To: <20040608110420.3b93338d@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5766 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: 354 Lines: 11 Stephen Hemminger wrote: > E1000 driver is mixing new style 'module_param' with old style 'MODULE_PARM' > this generates the runtime warning > e1000: Ignoring new-style parameters in presence of obsolete ones > and prevents using module parameters to set ring size. > > Signed-off-by: Stephen Hemminger why not fix the others? From ganesh.venkatesan@intel.com Tue Jun 8 11:42:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:42:22 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58IgGgi008393 for ; Tue, 8 Jun 2004 11:42:16 -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 i58BewUn008492; Tue, 8 Jun 2004 11:41:30 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i58IfvEn028155; Tue, 8 Jun 2004 18:42:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060811405812296 ; Tue, 08 Jun 2004 11:40:58 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 11:40:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] e1000 module parameter incompatiablity Date: Tue, 8 Jun 2004 11:40:57 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0158A420@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] e1000 module parameter incompatiablity Thread-Index: AcRNgw6a0rVs5mTxQyS9Lvf5Ec8PqgABQsWQ From: "Venkatesan, Ganesh" To: "Stephen Hemminger" Cc: "cramerj" , "Ronciak, John" , "Jeff Garzik" , X-OriginalArrivalTime: 08 Jun 2004 18:40:58.0995 (UTC) FILETIME=[241C6C30:01C44D88] 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 i58IgGgi008393 X-archive-position: 5767 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: 1222 Lines: 44 Applied to our development tree. Thanks, ganesh ------------------------------------------------- Ganesh Venkatesan Network/Storage Division, Hillsboro, OR -----Original Message----- From: Stephen Hemminger [mailto:shemminger@osdl.org] Sent: Tuesday, June 08, 2004 11:04 AM To: Venkatesan, Ganesh Cc: cramerj; Ronciak, John; Jeff Garzik; netdev@oss.sgi.com Subject: [PATCH] e1000 module parameter incompatiablity E1000 driver is mixing new style 'module_param' with old style 'MODULE_PARM' this generates the runtime warning e1000: Ignoring new-style parameters in presence of obsolete ones and prevents using module parameters to set ring size. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2004-06-08 11:01:58 -07:00 +++ b/drivers/net/e1000/e1000_main.c 2004-06-08 11:01:58 -07:00 @@ -202,8 +202,8 @@ MODULE_DESCRIPTION("Intel(R) PRO/1000 Network Driver"); MODULE_LICENSE("GPL"); -static int debug = 3; -module_param(debug, int, 0); +static int debug = NETIF_MSG_DRV | NETIF_MSG_PROBE; +MODULE_PARM(debug, "i"); MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); /** From jt@bougret.hpl.hp.com Tue Jun 8 11:48:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 11:48:40 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58ImVgi008811 for ; Tue, 8 Jun 2004 11:48:31 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 772E941477D; Tue, 8 Jun 2004 11:48:31 -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 LAA26174; Tue, 8 Jun 2004 11:49:41 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BXleB-00057r-00; Tue, 08 Jun 2004 11:48:31 -0700 Date: Tue, 8 Jun 2004 11:48:31 -0700 To: Vladimir Kondratiev , netdev@oss.sgi.com Subject: Re: in-driver QoS Message-ID: <20040608184831.GA18462@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: 5768 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: 2952 Lines: 76 Vladimir Kondratiev wrote : > > In 802.11 network, there is TGe (or 802.11e), working group, developing QoS > extensions for 802.11. 802.11e is about prioritisation of the traffic, not QoS. QoS is about bandwidth reservation and enforcement of policies, and 802.11e does none of that. > Now, question is: how will we support these QoS features in network stack? Simple : Linux driver should always send traffic at the highest priority, and never use the lowest priority. This way, we are guaranteed to always get the highest performance, and get higher benchmarks than Win32 or other OSes. > skb->priority help determining Tx queue, but fundamental problem is with > single Tx queue from network stack. Andi already corrected you about the fact that the net layer can offer multiple queue. If you look in .../net/sched/, you will see that skb->priority is used intensively, even for the generic scheduler. Most often, skb->priority is derived from sk->sk_priority, which is the socket priority. Andi Kleen wrote : > It already has that kind of in the form of arbitary qdiscs. The trick > will be only to do all queueing in the qdisc and keep the hardware > queue length as small as possible. I fully agree with that statement. One of the advantage of TC is that it enforces policies, which is more like real QoS. Note that the netdev queue is potentially larger than the hardware queue, especially with the recent increase due to Gigabit Ethernet, so there is more gain to be expected scheduling the netdev queue than the hardware queue in case of congestion. > Disadvantage will be more use of CPU time to refill driver > queues. More precisely, you increase the Tx-done interrupt frequency, so the number of context switches. The time to refill the queues remain the same. But, interrupt mitigation seems like a good thing in general. > BTW the standard qdisc pfifo_fast already has three queues, > selected by the old TOS. TOS is part of the IP header, and you don't want to read IP headers in the link layer, it's a clear layer violation. I think using skb->priority is a better way. Vladimir Kondratiev wrote : > > How could I use these multiple qdiscs? You need to enable "advanced router" in ***config and check pointers in this excellent howto : http://linux-ip.net/html/index.html (see section I.1.12) > I.e. I have 4 queues in the driver, I want to fill it separately, > start/stop incoming queues from stack etc. The driver is not the one deciding the policy, the network stack is. Therefore the driver accept whatever packet the network scheduler decide to give it and store it in the most appropriate queue (based on some meta-information such as skb->priority). This way the behavior of the driver is simple and predictable, you don't need to implement intserv/diffserv in the driver, and you can easily plug any scheduling you decide on top of it by reconfiguring the network stack. Have fun... Jean From hadi@cyberus.ca Tue Jun 8 12:11:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 12:11:12 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58JB8gi009509 for ; Tue, 8 Jun 2004 12:11:09 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BWbB0-0001ru-9C for netdev@oss.sgi.com; Sat, 05 Jun 2004 09:25:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BWbAt-0005If-GM; Sat, 05 Jun 2004 09:25:27 -0400 Subject: PATCH: Re: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Max Krasnyansky Cc: netdev@oss.sgi.com, syrius.ml@no-log.org, Jeff Garzik , "David S. Miller" In-Reply-To: <1084209482.758.15.camel@localhost> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> <1082719745.1057.27.camel@jzny.localdomain> <1082816083.1054.32.camel@jzny.localdomain> <1083007898.7788.276.camel@localhost> <1084017322.1041.30.camel@jzny.localdomain> <1084209482.758.15.camel@localhost> Content-Type: multipart/mixed; boundary="=-jsR7AYdCRp5xrNxzP/0m" Organization: jamalopolis Message-Id: <1086441896.1592.137.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jun 2004 09:24:56 -0400 X-archive-position: 5769 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: 2598 Lines: 82 --=-jsR7AYdCRp5xrNxzP/0m Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, trivial patch attached. Applies to both latest 2.6 and 2.4 I will go hunting for more drivers that do this; for now, a good start here. cheers, jamal On Mon, 2004-05-10 at 13:18, Max Krasnyansky wrote: > On Sat, 2004-05-08 at 04:55, jamal wrote: > > Max, Dave, Jeff, > > > > I get what was bothering me now - it took me a while to formulate it: > > > > TUN_TUN_DEV dev->type is ARPHRD_PPP > > dev->type is really related to link layer header, perhaps at the low > > level if neighbor discovery works well then we have a link-headerless > > packet which gets manipulated with the correct header by some generic > > code. The combination of dev->type and dev->hard_header_len works > > together to achieve this. > > In the case of TUN_TUN_DEV, the header_len is 0 ;-> > > To be of type ARPHRD_PPP, tun needs to have a header_len which is the > > size of the l2 ppp header. > > As an example, TUN_TAP_DEV is fine as type ARPHRD_ETHER and header_len > > of ETH_HLEN. > > > > A lot of devices are abusing this system, tun is not the only one. > > > > My suggestion is to change dev->type to ARPHRD_VOID for TUN_TUN_DEV or > > we introduce something like ARPHDR_NONE for devices with link layer > > headers of size 0. > > > > thoughts? > > I have no problem with that. I mean introducing new ARPHDR_ type. > ARPHDR_PPP was simply most appropriate for TUN that's why I picked it. > I vote for ARPHDR_NONE. > > Thanks > Max > > > > --=-jsR7AYdCRp5xrNxzP/0m Content-Disposition: attachment; filename=tun24 Content-Type: text/plain; name=tun24; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- /usr/src/2426/include/linux/if_arp.h 2002-02-25 14:38:13.000000000 -0500 +++ /usr/src/2426-mod/include/linux/if_arp.h 2004-06-04 15:10:15.000000000 -0400 @@ -85,6 +85,7 @@ #define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */ #define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */ +#define ARPHRD_NONE 0xFFFE /* zero header length */ /* ARP protocol opcodes. */ #define ARPOP_REQUEST 1 /* ARP request */ --- /usr/src/2426/drivers/net/tun.c 2002-08-02 20:39:44.000000000 -0400 +++ /usr/src/2426-mod/drivers/net/tun.c 2004-06-04 15:10:50.000000000 -0400 @@ -138,8 +138,8 @@ dev->addr_len = 0; dev->mtu = 1500; - /* Type PPP seems most suitable */ - dev->type = ARPHRD_PPP; + /* Zero header length */ + dev->type = ARPHRD_NONE; dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST; dev->tx_queue_len = 10; break; --=-jsR7AYdCRp5xrNxzP/0m-- From felipe_alfaro@linuxmail.org Tue Jun 8 12:18:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 12:18:42 -0700 (PDT) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58JIUgi010283 for ; Tue, 8 Jun 2004 12:18:35 -0700 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 2284B42E42 for ; Tue, 8 Jun 2004 21:18:18 +0200 (CEST) Subject: 2.6.7-rc3: waiting for eth0 to become free From: Felipe Alfaro Solana To: NetDev Mailinglist Content-Type: text/plain Date: Tue, 08 Jun 2004 21:18:30 +0200 Message-Id: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 (1.5.9.1-1) Content-Transfer-Encoding: 7bit X-archive-position: 5771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: netdev Content-Length: 814 Lines: 19 Hi! On my laptop, when using a CardBus 3c59x-based NIC, I need to run "cardctl eject" so the system won't freeze when resuming. "cardctl eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with network sockets opened (for example, Evolution mantaining a connection against an IMAP server): the card is ejected (well, not physically), even when there are ESTABLISHED connections. However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program holds any socket open. After a while the "unregister_netdevice: waiting for eth0 to become free" message starts appearing on the kernel message ring. The only apparent solution is killing that program, ejecting the card from its slot and wait until 3c59x.o usage count reaches zero. Can someone tell me what's going on here? Thank you very much. From shemminger@osdl.org Tue Jun 8 12:40:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 12:40:40 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58JeZgi013971 for ; Tue, 8 Jun 2004 12:40:36 -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 i58JdXr15560; Tue, 8 Jun 2004 12:39:33 -0700 Date: Tue, 8 Jun 2004 12:39:33 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: "Venkatesan, Ganesh" , cramerj , "Ronciak, John" , netdev@oss.sgi.com Subject: Re: [PATCH] e1000 module parameter incompatiablity Message-Id: <20040608123933.70816c41@dell_ss3.pdx.osdl.net> In-Reply-To: <40C607D9.5090506@pobox.com> References: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> <20040608110420.3b93338d@dell_ss3.pdx.osdl.net> <40C607D9.5090506@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: 5772 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: 498 Lines: 14 On Tue, 08 Jun 2004 14:39:21 -0400 Jeff Garzik wrote: > Stephen Hemminger wrote: > > E1000 driver is mixing new style 'module_param' with old style 'MODULE_PARM' > > this generates the runtime warning > > e1000: Ignoring new-style parameters in presence of obsolete ones > > and prevents using module parameters to set ring size. > > > > Signed-off-by: Stephen Hemminger > > why not fix the others? Cause their buried in ugly macros in another place. From shemminger@osdl.org Tue Jun 8 12:42:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 12:42:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58JgNgi014341 for ; Tue, 8 Jun 2004 12:42: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 i58JgFr15863; Tue, 8 Jun 2004 12:42:15 -0700 Date: Tue, 8 Jun 2004 12:42:15 -0700 From: Stephen Hemminger To: Felipe Alfaro Solana Cc: NetDev Mailinglist Subject: Re: 2.6.7-rc3: waiting for eth0 to become free Message-Id: <20040608124215.291a7072@dell_ss3.pdx.osdl.net> In-Reply-To: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.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: 5773 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: 989 Lines: 22 On Tue, 08 Jun 2004 21:18:30 +0200 Felipe Alfaro Solana wrote: > Hi! > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > "cardctl eject" so the system won't freeze when resuming. "cardctl > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > network sockets opened (for example, Evolution mantaining a connection > against an IMAP server): the card is ejected (well, not physically), > even when there are ESTABLISHED connections. > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > holds any socket open. After a while the "unregister_netdevice: waiting > for eth0 to become free" message starts appearing on the kernel message > ring. The only apparent solution is killing that program, ejecting the > card from its slot and wait until 3c59x.o usage count reaches zero. > > Can someone tell me what's going on here? > Thank you very much. What protocols are you running? Is IPV6 loaded? From jt@bougret.hpl.hp.com Tue Jun 8 12:52:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 12:52:45 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58Jqdgi014831 for ; Tue, 8 Jun 2004 12:52:39 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id E2CB81C1520D; Tue, 8 Jun 2004 12:52:38 -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 MAA27861; Tue, 8 Jun 2004 12:53:48 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BXmeE-0005am-00; Tue, 08 Jun 2004 12:52:38 -0700 Date: Tue, 8 Jun 2004 12:52:38 -0700 To: jamal Cc: netdev@oss.sgi.com Subject: Re: in-driver QoS Message-ID: <20040608195238.GA21089@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040608184831.GA18462@bougret.hpl.hp.com> <1086722317.1023.18.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086722317.1023.18.camel@jzny.localdomain> 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: 5774 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: 2661 Lines: 56 On Tue, Jun 08, 2004 at 03:18:37PM -0400, jamal wrote: > On Tue, 2004-06-08 at 14:48, Jean Tourrilhes wrote: > > Vladimir Kondratiev wrote : > > > > > > In 802.11 network, there is TGe (or 802.11e), working group, developing QoS > > > extensions for 802.11. > > > > 802.11e is about prioritisation of the traffic, not QoS. QoS > > is about bandwidth reservation and enforcement of policies, and > > 802.11e does none of that. > > Prioritization is a subset of QoS. So if 802.11e talks prioritization, > thats precisely what it means - QoS. Yes, it's one component of a QoS solution. But, my point is that on it's own, it's not enough. This means that we should not see 802.11e as a complete QoS solution, and the center of the QoS universe, but only as a mechanism that need to be integrated in the QoS solution. Which means, instead of trying to fit TC in 802.11e, we need to fit 802.11e in TC. That's a totally different perspective. > The guy has some valid points in terms of multiple DMA rings if i > understood him correctly. Theres current architectural deficiencies. I don't buy that. The multiple DMA ring is not the main thing here, all DMA transfer share the same I/O bus to the card and share the same memory pool, so there is no real performance gain there. The I/O bnandwidth to the card is vastly superior to the medium bandwidth, so the DMA process will never be a bottleneck. The real benefit is that the contention on the medium is prioritised (between contenting nodes). The contention process (CSMA, backoff, and all the jazz) will give a preference to stations with packet of the highest priority compared to stations wanting to send packet of lower priorities. To gain advantage of that, you only need to assign your packet the right priority at the driver level, and the CSMA will send it appropriately. With respect to the 4 different hardware queue, you should see them only as an extension of the netdev queues. Basically, you just have a pipeline between the scheduler and the MAC which is almost a FIFO, but not exactly a FIFO. Those queues may do packet reordering between themselves, based on priorities. But at the end of the day they are only going to send what the scheduler is feeding them, and every packet the scheduler pass to those queues is eventually sent, so they are totally slave to the scheduler. So, I would not worry about the DMA rings. I may worry a little bit about packet reordering between queues, but I don't think it's a problem. And about the new contention behaviour, this is only between different stations, not within a node, so it won't impact you. > cheers, > jamal Have fun... Jean From jgarzik@pobox.com Tue Jun 8 13:05:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 13:05: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.12.10/8.12.9) with SMTP id i58K5Lgi015677 for ; Tue, 8 Jun 2004 13:05:24 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BXlT6-0006Xu-37; Tue, 08 Jun 2004 19:37:04 +0100 Message-ID: <40C60744.7010803@pobox.com> Date: Tue, 08 Jun 2004 14:36:52 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Feldman CC: netdev@oss.sgi.com, jesse.brandeburg@intel.com Subject: Re: [PATCH 2.4] e1000: fix napi crash on ifdown during traffic References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5776 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 applied From felipe_alfaro@linuxmail.org Tue Jun 8 13:09:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 13:09:32 -0700 (PDT) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58K9Pgi016054 for ; Tue, 8 Jun 2004 13:09:26 -0700 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 5C5BF42D1B; Tue, 8 Jun 2004 22:09:18 +0200 (CEST) Subject: Re: 2.6.7-rc3: waiting for eth0 to become free From: Felipe Alfaro Solana To: Stephen Hemminger Cc: NetDev Mailinglist In-Reply-To: <20040608124215.291a7072@dell_ss3.pdx.osdl.net> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> Content-Type: text/plain Date: Tue, 08 Jun 2004 22:09:29 +0200 Message-Id: <1086725369.1806.1.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 (1.5.9.1-1) Content-Transfer-Encoding: 7bit X-archive-position: 5777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: netdev Content-Length: 1172 Lines: 28 On Tue, 2004-06-08 at 12:42 -0700, Stephen Hemminger wrote: > On Tue, 08 Jun 2004 21:18:30 +0200 > Felipe Alfaro Solana wrote: > > > Hi! > > > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > > "cardctl eject" so the system won't freeze when resuming. "cardctl > > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > > network sockets opened (for example, Evolution mantaining a connection > > against an IMAP server): the card is ejected (well, not physically), > > even when there are ESTABLISHED connections. > > > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > > holds any socket open. After a while the "unregister_netdevice: waiting > > for eth0 to become free" message starts appearing on the kernel message > > ring. The only apparent solution is killing that program, ejecting the > > card from its slot and wait until 3c59x.o usage count reaches zero. > > > > Can someone tell me what's going on here? > > Thank you very much. > > What protocols are you running? Is IPV6 loaded? I'm using IPv4, IPv6 and IPSec ESP with AES/CBC. Do you want .config? Thanks From vkondra@mail.ru Tue Jun 8 13:41:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 13:41:35 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58KfPgi016991 for ; Tue, 8 Jun 2004 13:41:28 -0700 Received: from [212.179.218.36] (port=39906 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BXnPH-000A1Q-00 for netdev@oss.sgi.com; Wed, 09 Jun 2004 00:41:17 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: how to interpret C statement? Date: Tue, 8 Jun 2004 23:41:06 +0300 User-Agent: KMail/1.6.2 References: <20040608154412.14868.qmail@web52208.mail.yahoo.com> In-Reply-To: <20040608154412.14868.qmail@web52208.mail.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406082341.06598.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5778 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: 544 Lines: 18 Easy. skb-cb used to keep struct tcp_skb_cb. Statement in your question do casting and return pointer to the structure. On Tuesday 08 June 2004 18:44, linux lover wrote: > how to interpret following C statement? > #define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0])) > what is use of tcp_skb_cb structure in kernel source tcp.h? how > TCP_SKB_CB(skb) is translated in its definition? regards, > linux_lover > > > > > > > --------------------------------- > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger From hadi@cyberus.ca Tue Jun 8 13:55:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 13:55:53 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58Ktmgi017930 for ; Tue, 8 Jun 2004 13:55:48 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BXndK-0004gz-Oc for netdev@oss.sgi.com; Tue, 08 Jun 2004 16:55:46 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BXndE-000455-9Y; Tue, 08 Jun 2004 16:55:40 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: jt@hpl.hp.com Cc: netdev@oss.sgi.com In-Reply-To: <20040608195238.GA21089@bougret.hpl.hp.com> References: <20040608184831.GA18462@bougret.hpl.hp.com> <1086722317.1023.18.camel@jzny.localdomain> <20040608195238.GA21089@bougret.hpl.hp.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086728139.1023.71.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jun 2004 16:55:39 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5779 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: 2927 Lines: 65 On Tue, 2004-06-08 at 15:52, Jean Tourrilhes wrote: > On Tue, Jun 08, 2004 at 03:18:37PM -0400, jamal wrote: > > Prioritization is a subset of QoS. So if 802.11e talks prioritization, > > thats precisely what it means - QoS. > > Yes, it's one component of a QoS solution. But, my point is > that on it's own, it's not enough. There is no mapping or exclusivity of QoS to bandwidth reservation. The most basic QoS and most popular QoS mechanisms even on Linux is just prioritization and nothing to do with bandwidth allocation. > > The guy has some valid points in terms of multiple DMA rings if i > > understood him correctly. Theres current architectural deficiencies. > > I don't buy that. The multiple DMA ring is not the main thing > here, all DMA transfer share the same I/O bus to the card and share > the same memory pool, so there is no real performance gain there. The > I/O bnandwidth to the card is vastly superior to the medium bandwidth, > so the DMA process will never be a bottleneck. According to Vladimir the wireless piece of it is different. i.e each DMA ring will get different 802.11 channels with different backoff and contention window parameters. So nothing to do with the DMA process being a bottleneck. Help me understand this better: theres a wired side and a wireless side or are both send and receive interafacing to the air? > The real benefit is that the contention on the medium is > prioritised (between contenting nodes). The contention process (CSMA, > backoff, and all the jazz) will give a preference to stations with > packet of the highest priority compared to stations wanting to send > packet of lower priorities. To gain advantage of that, you only need > to assign your packet the right priority at the driver level, and the > CSMA will send it appropriately. Yes, but how does the CSMA figure that? Is it not from the different DMA rings? > With respect to the 4 different hardware queue, you should see > them only as an extension of the netdev queues. Basically, you just > have a pipeline between the scheduler and the MAC which is almost a > FIFO, but not exactly a FIFO. Those queues may do packet reordering > between themselves, based on priorities. But at the end of the day > they are only going to send what the scheduler is feeding them, and > every packet the scheduler pass to those queues is eventually sent, so > they are totally slave to the scheduler. Is it a FIFO or there are several DMA rings involved? If the later: when do you stop the netdevice (i.e call netif_stop_queue())? > So, I would not worry about the DMA rings. I may worry a > little bit about packet reordering between queues, but I don't think > it's a problem. And about the new contention behaviour, this is only > between different stations, not within a node, so it won't impact you. Anyone putting different packets from same flow cant guarantee ordering. cheers, jamal From shemminger@osdl.org Tue Jun 8 14:02:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 14:02:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58L26gi018433 for ; Tue, 8 Jun 2004 14:02:06 -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 i58L20r29381; Tue, 8 Jun 2004 14:02:00 -0700 Date: Tue, 8 Jun 2004 14:02:00 -0700 From: Stephen Hemminger To: Felipe Alfaro Solana Cc: NetDev Mailinglist Subject: Re: 2.6.7-rc3: waiting for eth0 to become free Message-Id: <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> In-Reply-To: <1086725369.1806.1.camel@teapot.felipe-alfaro.com> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.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: 5780 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: 1768 Lines: 38 On Tue, 08 Jun 2004 22:09:29 +0200 Felipe Alfaro Solana wrote: > On Tue, 2004-06-08 at 12:42 -0700, Stephen Hemminger wrote: > > On Tue, 08 Jun 2004 21:18:30 +0200 > > Felipe Alfaro Solana wrote: > > > > > Hi! > > > > > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > > > "cardctl eject" so the system won't freeze when resuming. "cardctl > > > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > > > network sockets opened (for example, Evolution mantaining a connection > > > against an IMAP server): the card is ejected (well, not physically), > > > even when there are ESTABLISHED connections. > > > > > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > > > holds any socket open. After a while the "unregister_netdevice: waiting > > > for eth0 to become free" message starts appearing on the kernel message > > > ring. The only apparent solution is killing that program, ejecting the > > > card from its slot and wait until 3c59x.o usage count reaches zero. > > > > > > Can someone tell me what's going on here? > > > Thank you very much. > > > > What protocols are you running? Is IPV6 loaded? > > I'm using IPv4, IPv6 and IPSec ESP with AES/CBC. > Do you want .config? Not really, could you see if it is an IPv6 vs IPSec problem by not running/loading one or the other. What is happening is that some subsystem is holding a reference to the device (calling dev_hold()) but not cleaning up (calling dev_put). It can be a hard to track which of the many things routing, etc are not being cleared properly. Look for routes that still get stuck (ip route) and neighbor cache entries. Most of these end up being protocol bugs. From fubar@us.ibm.com Tue Jun 8 14:27:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 14:27:08 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58LQrgi019570 for ; Tue, 8 Jun 2004 14:27:00 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i58LQeQ1431970; Tue, 8 Jun 2004 17:26:40 -0400 Received: from death.nxdomain.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i58LRK43122626; Tue, 8 Jun 2004 17:27:21 -0400 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id i58LQZpf006017; Tue, 8 Jun 2004 14:26:35 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i58LQZO5006010; Tue, 8 Jun 2004 14:26:35 -0700 Message-Id: <200406082126.i58LQZO5006010@death.nxdomain.ibm.com> To: netdev@oss.sgi.com Cc: "Feldman, Scott" Subject: [PATCH 2.6] e100: 1/2 fix skb leak in tx timeout X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 08 Jun 2004 14:26:35 -0700 From: Jay Vosburgh X-archive-position: 5781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1025 Lines: 33 If e100 experiences a transmit timeout, and the tx ring is completely full at that time, it will leak all of the skbs on the tx ring (because extra logic is needed to distinguish ring full from ring empty). -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com diff -urN linux-2.6.6-virgin/drivers/net/e100.c linux-2.6.6/drivers/net/e100.c --- linux-2.6.6-virgin/drivers/net/e100.c 2004-06-08 13:51:34.000000000 -0700 +++ linux-2.6.6/drivers/net/e100.c 2004-06-08 13:52:37.000000000 -0700 @@ -1322,7 +1322,8 @@ static void e100_clean_cbs(struct nic *nic) { if(nic->cbs) { - while(nic->cb_to_clean != nic->cb_to_use) { + while((nic->cb_to_clean != nic->cb_to_use) || + (0 == nic->cbs_avail)) { struct cb *cb = nic->cb_to_clean; if(cb->skb) { pci_unmap_single(nic->pdev, @@ -1332,6 +1333,7 @@ dev_kfree_skb(cb->skb); } nic->cb_to_clean = nic->cb_to_clean->next; + nic->cbs_avail++; } nic->cbs_avail = nic->params.cbs.count; pci_free_consistent(nic->pdev, From fubar@us.ibm.com Tue Jun 8 14:27:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 14: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.12.10/8.12.9) with SMTP id i58LRkgi019731 for ; Tue, 8 Jun 2004 14:27:46 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i58LRbwc507410; Tue, 8 Jun 2004 17:27:37 -0400 Received: from death.nxdomain.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i58LRXPN196194; Tue, 8 Jun 2004 15:27:35 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id i58LRVpf006029; Tue, 8 Jun 2004 14:27:31 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i58LRVZm006023; Tue, 8 Jun 2004 14:27:31 -0700 Message-Id: <200406082127.i58LRVZm006023@death.nxdomain.ibm.com> To: netdev@oss.sgi.com Cc: "Feldman, Scott" Subject: [PATCH 2.6] e100: 2/2 fix sender hang after tx timeout X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 08 Jun 2004 14:27:31 -0700 From: Jay Vosburgh X-archive-position: 5782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1446 Lines: 35 Simple patch, long description. When e100 experiences a transmit timeout, it calls e100_up() to reset the device. Among other things, e100_up() calls netif_start_queue() to release any flow block. If a socket (in my test case, a packet socket sending minimum size packets in a loop) is blocked in sendto() due to flow blockage, it will never wake up, because nothing will run the queue (netif_start_queue() just clears flow block, it does not schedule). After a tx timeout, the tx ring is empty, so no transmit interrupts will arrive, and no new packets will be sent down because the device queue is full. A fix is to call netif_schedule() after e100_up() is complete. Calling netif_start_queue() won't work, because it only schedules if called with the device flow blocked (which we've already cleared in e100_up()). There might be a better way to do this, but this confines the change to e100_tx_timeout(). -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com diff -urN linux-2.6.6-semi-virgin/drivers/net/e100.c linux-2.6.6/drivers/net/e100.c --- linux-2.6.6-semi-virgin/drivers/net/e100.c 2004-06-08 13:54:37.000000000 -0700 +++ linux-2.6.6/drivers/net/e100.c 2004-06-08 13:54:58.000000000 -0700 @@ -1697,6 +1697,7 @@ readb(&nic->csr->scb.status)); e100_down(netdev->priv); e100_up(netdev->priv); + netif_schedule(netdev); } static int e100_loopback_test(struct nic *nic, enum loopback loopback_mode) From jt@bougret.hpl.hp.com Tue Jun 8 15:01:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 15:01:17 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i58M1Agi020762 for ; Tue, 8 Jun 2004 15:01:10 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id B842E1C00231; Tue, 8 Jun 2004 15:01:09 -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 PAA01626; Tue, 8 Jun 2004 15:02:19 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BXoeb-0006bN-00; Tue, 08 Jun 2004 15:01:09 -0700 Date: Tue, 8 Jun 2004 15:01:09 -0700 To: jamal Cc: netdev@oss.sgi.com Subject: Re: in-driver QoS Message-ID: <20040608220109.GA24536@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040608184831.GA18462@bougret.hpl.hp.com> <1086722317.1023.18.camel@jzny.localdomain> <20040608195238.GA21089@bougret.hpl.hp.com> <1086728139.1023.71.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086728139.1023.71.camel@jzny.localdomain> 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: 5783 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: 5471 Lines: 119 On Tue, Jun 08, 2004 at 04:55:39PM -0400, jamal wrote: > On Tue, 2004-06-08 at 15:52, Jean Tourrilhes wrote: > > On Tue, Jun 08, 2004 at 03:18:37PM -0400, jamal wrote: > > > Prioritization is a subset of QoS. So if 802.11e talks prioritization, > > > thats precisely what it means - QoS. > > > > Yes, it's one component of a QoS solution. But, my point is > > that on it's own, it's not enough. > > There is no mapping or exclusivity of QoS to bandwidth reservation. > The most basic QoS and most popular QoS mechanisms even on Linux is > just prioritization and nothing to do with bandwidth allocation. The difference is that the Linux infrastructure can do it, even if you don't do it, the 802.11e can't. Whatever, it does not matter. > > I don't buy that. The multiple DMA ring is not the main thing > > here, all DMA transfer share the same I/O bus to the card and share > > the same memory pool, so there is no real performance gain there. The > > I/O bnandwidth to the card is vastly superior to the medium bandwidth, > > so the DMA process will never be a bottleneck. > > According to Vladimir the wireless piece of it is different. > i.e each DMA ring will get different 802.11 channels Nope they can't get to different wireless channel, unless you have two radio modem in your hardware. If you have two radio hardware, then you might as well present two virtual devices. The standard 802.11e (EDCF/HCF) is mostly a modification of the contention process on the medium, everything happens on the same wireless channel. Vladimir's use of "channel" is confusing, but I think he meant a virtual channel in the hardware, or something else. > with different backoff and contention window parameters. Yep. This impact the contention process. This is similar to what was implemented in 100VG / IEEE 802.12, but in more elaborated. > So nothing to do with the DMA process being a bottleneck. You were the one worried about having multiple DMA rings. > Help me understand this better: > theres a wired side and a wireless side or are both send and receive > interafacing to the air? This is like old coax-Ethernet, but instead of having a common coax cable, you have a single wireless channel shared by all stations. For more details, please look in my Wireless Howto. Both send and receive are done on the same frequency. The other side of the hardware plug in the PCI bus. > > The real benefit is that the contention on the medium is > > prioritised (between contenting nodes). The contention process (CSMA, > > backoff, and all the jazz) will give a preference to stations with > > packet of the highest priority compared to stations wanting to send > > packet of lower priorities. To gain advantage of that, you only need > > to assign your packet the right priority at the driver level, and the > > CSMA will send it appropriately. > > Yes, but how does the CSMA figure that? Is it not from the different > DMA rings? Yes. So, what the drivers need to do in the xmit handler is to figure out what is the packet priority (probably using skb->priority or another mechanism) and put it in the appropriate queue/ring/FIFO. > Is it a FIFO or there are several DMA rings involved? If the later: > when do you stop the netdevice (i.e call netif_stop_queue())? There is 4 FIFOs (or whichever number then want to configure) in parallel. Most likely, the FIFOs will share the same memory pool on the card, so when a FIFO is full, most likely the other FIFOs will be full or close to it. In theory, they could dedicate card memory to each FIFO. But, in such case, if one FIFO is full and the other empty, it means that the card scheduler doesn't process packets according to the netdev scheduler. The netdev scheduler is the authoritative one, because directly controled by the policy and the intserv/diffserv software. Therefore you really want the card scheduler to start draining the full FIFO before we resume sending to the other FIFOs, otherwise the card scheduler will biased the policy netdev tries to enforce. So, in any case, my suggestion would be to netif_stop_queue() as soon as one FIFO is full, and to netif_wake_queue() as soon as all FIFO have space. This is the most simple and predictable solution. But, we are talking there as if the hardware was going to have some incredibly smart scheduler across FIFOs. From my experience with wireless MAC implementations, the behaviour will be really simplistic (always send from the highest priority FIFO), if not totally broken. And you will probably have very little control over it in low end cards (hardwired ?). This is why I would not trust MAC level scheduling (within a single host), and my concern is more to avoid the card scheduler to mess up netdev scheduling (which is a known quantity) rather than try to find way to take advantage of it. > > So, I would not worry about the DMA rings. I may worry a > > little bit about packet reordering between queues, but I don't think > > it's a problem. And about the new contention behaviour, this is only > > between different stations, not within a node, so it won't impact you. > > Anyone putting different packets from same flow cant guarantee ordering. For performance reason, because of TCP behaviour, you really want to keep packets of a flow ordered. I agree that keeping ordering across flow in non realistic, because the point of QoS is to reorder packet across flows. > cheers, > jamal Have fun... Jean From akpm@osdl.org Tue Jun 8 17:01:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 17:01:53 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5901jgi026749 for ; Tue, 8 Jun 2004 17:01:45 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i5901er29899; Tue, 8 Jun 2004 17:01:40 -0700 Date: Tue, 8 Jun 2004 17:04:27 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: atlaste@yahoo.com Subject: Fw: [Bugme-new] [Bug 2851] New: System takes 100% CPU and kernel log has *loads* of assertions Message-Id: <20040608170427.51615bde.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5784 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: 3018 Lines: 80 Begin forwarded message: Date: Tue, 8 Jun 2004 16:44:13 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 2851] New: System takes 100% CPU and kernel log has *loads* of assertions http://bugme.osdl.org/show_bug.cgi?id=2851 Summary: System takes 100% CPU and kernel log has *loads* of assertions Kernel Version: 2.6.6 Status: NEW Severity: high Owner: niv@us.ibm.com Submitter: atlaste@yahoo.com Distribution:Debian Hardware Environment: Small piece of lspci: 0000:02:05.0 Ethernet controller: Marvell Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) 0000:02:0a.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05) Furthermore, it's an intel ich-5r motherboard from ASUS: P4P800E-deluxe (http://www.asus.com/prog/spec.asp?m=P4P800-E%20Deluxe&langs=01) The first ethernet controller appears to be causing the problem. However, it should be noted that the first ethernet controller is used way more often, while the latter is merely used for internal traffic. The first ethernet controller is on a LAN with 1500+ computers. This also means weird stuff could be happening here, although I think that's unlikely in this case, when looking at when the problems are occurring. Software Environment: Nothing special, running a number of services. Problem Description: The log should provide enough information. Somehow it appears SSHD causes the problem, perhaps in combination with a screen, and it is caused at arbitrary times. (about 2 times a day sometimes). This is just a small snippet; my entire HD ran full with 50GB of logs because of this bug, in merely two hours. May 24 12:34:28 swing kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1571) May 24 12:34:28 swing kernel: KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1635) May 24 12:34:28 swing kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1571) May 24 12:34:28 swing kernel: KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1635) May 24 12:34:28 swing kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1571) May 24 12:34:28 swing kernel: KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1635) May 24 12:34:28 swing kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1571) May 24 12:34:28 swing kernel: KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1635) Steps to reproduce: Not entirely sure. Usually I login with SSH and the bug arbitrarily emerges. As a last note: 2.6.4 appeared to have this problem too. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jm@jm.kir.nu Tue Jun 8 20:46:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 20:46:29 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i593k8gi003401 for ; Tue, 8 Jun 2004 20:46:08 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BXu26-0004Qi-HI; Tue, 08 Jun 2004 20:45:46 -0700 Date: Tue, 8 Jun 2004 20:45:46 -0700 From: Jouni Malinen To: Jean Tourrilhes Cc: netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support Message-ID: <20040609034546.GA7347@jm.kir.nu> References: <20040607023455.GA10424@jm.kir.nu> <20040608002659.GA18087@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608002659.GA18087@bougret.hpl.hp.com> User-Agent: Mutt/1.5.6i X-archive-position: 5785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 13407 Lines: 375 On Mon, Jun 07, 2004 at 05:26:59PM -0700, Jean Tourrilhes wrote: > Actually, I don't like the extension of SIOC*IWENCODE. This > ioctl is already messy/complex enough as it is, and I think we would > benefit greatly in separating the two code paths, therefore using a > new iotcl for it. It's not like we are short of ioctls. OK. > The extension of SIOCSIWSCAN was always something desired, but > I never got sure of which way it was supposed to be done (look at the > unused IW_SCAN_* flags in wireless.h). > Do you think that ESSID is the only request filter that is > worthwhile ? Another option would be to allow an "iwevent" structure > allow to specify any kind of filter. Yes, there are other parameters that may be useful at some point. Actually, IEEE 802.11 specifies this list as parameters to MLME-SCAN.request and I changed struct iw_scan_req to include all the parameters. I would assume many drivers would not include some of the timing values, but at least this should cover all cases mentioned in the standard. > It took me a while to understand how this one is supposed to > works (which means that it may need better documentation). It's a > sub-ioctl kind of thing, right ? The SET accept two 32 bit integers, > the GET accept one and return one. sub-ioctl kind, but in that way.. I agree on the lack of documentation part. > You current definition doesn't work, because you are using > IW_HEADER_TYPE_PARAM that carry only a single 32bit integer. There are > two solutions. The first is fit the IW_AUTH_INDEX in the 16 bits of > iw_param->flags. The second is to use IW_HEADER_TYPE_UINT. struct iw_param has 16-bit flags field and my definition was trying to make it clear that that was indeed used for the IW_AUTH_* index numbers. In other words, I was using the first solution you list here. I added some more explicit text to make this clear. > Also, all the constant used for this command should have the > IW_AUTH_* prefix (IW_CIPHER_NONE => IW_AUTH_CIPHER_NONE), so that we > can see clearly that they apply to this command. I would even go > futher and have common prefixes between request and values : OK. > I think that "supported_feature" is too generic a name for > what you are using it now. As there are other "supported_feature" type > of fields in iw_range (pm_capa, txpower_capa, retry_capa), I would > suggest to use a more descriptive name, such as "enc_features" or > "enc_capa". My bad.. I didn't look at existing fields in struct iw_range and I didn't even remember that I have actually used those before ;-). Changed to enc_capa to match with existing fields. > > +/* IEEE 802.11 MLME requests */ > > +#define SIOCSIWMLME 0x8B30 /* request MLME operation */ > > I don't see a struct for it, so I assume the format of that is > defined somewhere in the 802.11 spec ? May be worth documenting where > to look for it. struct iw_mlme (and yes, it is based on IEEE 802.11, but does not include all parameters for all possible MLME requests). > I hope I did not sound too "picky", but I hope that my > suggestion are not too difficult to implement while adding some > value. Tell me what you think ;-) Thanks for all comments. That was not at all picky; I think I agreed with everything. Here's an updated version of the patch (again, not yet tested, so not ready to be applied). Please let me know if I missed something. ===== include/linux/wireless.h 1.9 vs edited ===== --- 1.9/include/linux/wireless.h Fri Apr 16 13:56:10 2004 +++ edited/include/linux/wireless.h Tue Jun 8 20:43:09 2004 @@ -1,7 +1,7 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 6.8.04 * * Authors : Jean Tourrilhes - HPL - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,19 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * ---------- + * - Add support for WPA/WPA2 + * - Add extended encoding configuration (SIOCSIWENCODEEXT and + * SIOCGIWENCODEEXT) + * - Add SIOCSIWGENIE/SIOCGIWGENIE + * - Add SIOCSIWMLME + * - Add struct iw_range bit field for supported encoding capabilities + * - Add optional parameter structure for SIOCSIWSCAN + * - Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA + * related parameters (extensible up to 4096 parameter values) + * - Add wireless events: IWEVWPAIE, IWEVRSNIE, IWEVMICHAELMICFAILURE */ /**************************** CONSTANTS ****************************/ @@ -249,6 +262,22 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +/* Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WME) */ +#define SIOCSIWGENIE 0x8B2E /* set generic IE */ +#define SIOCGIWGENIE 0x8B2F /* get generic IE */ + +/* IEEE 802.11 MLME requests */ +#define SIOCSIWMLME 0x8B30 /* request MLME operation; uses + * struct iw_scan_req */ + +/* Authentication mode parameters */ +#define SIOCSIWAUTH 0x8B31 /* set authentication mode params */ +#define SIOCGIWAUTH 0x8B32 /* get authentication mode params */ + +/* Extended version of encoding configuration */ +#define SIOCSIWENCODEEXT 0x8B33 /* set encoding token & mode */ +#define SIOCGIWENCODEEXT 0x8B34 /* get encoding token & mode */ + /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ /* These 16 ioctl are wireless device private. @@ -290,6 +319,11 @@ #define IWEVCUSTOM 0x8C02 /* Driver specific ascii string */ #define IWEVREGISTERED 0x8C03 /* Discovered a new node (AP mode) */ #define IWEVEXPIRED 0x8C04 /* Expired a node (AP mode) */ +#define IWEVWPAIE 0x8C05 /* WPA IE (scan results) */ +#define IWEVRSNIE 0x8C06 /* RSN IE (WPA2) (scan results) */ +#define IWEVMICHAELMICFAILURE 0x8C07 /* Michael MIC failure + * (struct iw_michaelmicfailure) + */ #define IWEVFIRST 0x8C00 @@ -370,6 +404,33 @@ #define IW_ENCODE_NOKEY 0x0800 /* Key is write only, so not present */ #define IW_ENCODE_TEMP 0x0400 /* Temporary key */ +#define IW_ENCODE_SEQ_MAX_SIZE 8 + +#define IW_ENCODE_ALG_NONE 0 +#define IW_ENCODE_ALG_WEP 1 +#define IW_ENCODE_ALG_TKIP 2 +#define IW_ENCODE_ALG_CCMP 3 + +/* IW_AUTH_WPA_VERSION values */ +#define IW_AUTH_WPA_VERSION_DISABLED 0 +#define IW_AUTH_WPA_VERSION_WPA 1 +#define IW_AUTH_WPA_VERSION_WPA2 2 + +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values */ +#define IW_AUTH_CIPHER_NONE 0 +#define IW_AUTH_CIPHER_WEP40 1 +#define IW_AUTH_CIPHER_TKIP 2 +#define IW_AUTH_CIPHER_CCMP 4 +#define IW_AUTH_CIPHER_WEP104 5 + +/* IW_AUTH_KEY_MGMT values */ +#define IW_AUTH_KEY_MGMT_802_1X 1 +#define IW_AUTH_KEY_MGMT_PSK 2 + +/* IW_AUTH_80211_AUTH_ALG values (bit field) */ +#define IW_AUTH_ALG_OPEN_SYSTEM 0x00000001 +#define IW_AUTH_ALG_SHARED_KEY 0x00000002 + /* Power management flags available (along with the value, if any) */ #define IW_POWER_ON 0x0000 /* No details... */ #define IW_POWER_TYPE 0xF000 /* Type of parameter */ @@ -412,12 +473,46 @@ #define IW_SCAN_THIS_MODE 0x0020 /* Scan only this Mode */ #define IW_SCAN_ALL_RATE 0x0040 /* Scan all Bit-Rates */ #define IW_SCAN_THIS_RATE 0x0080 /* Scan only this Bit-Rate */ + +/* struct iw_scan_req scan_type */ +#define IW_SCAN_TYPE_ACTIVE 0 +#define IW_SCAN_TYPE_PASSIVE 1 + /* Maximum size of returned data */ #define IW_SCAN_MAX_DATA 4096 /* In bytes */ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Generic information element */ +#define IW_GENERIC_IE_MAX 256 + +/* MLME requests (SIOCSIWMLME / struct iw_mlme) */ +#define IW_MLME_DEAUTH 0 +#define IW_MLME_DISASSOC 1 + +/* Bit field values for enc_capa in struct iw_range */ +#define IW_ENC_CAPA_WPA 0x00000001 +#define IW_ENC_CAPA_WPA2 0x00000002 +#define IW_ENC_CAPA_CIPHER_TKIP 0x00000004 +#define IW_ENC_CAPA_CIPHER_CCMP 0x00000008 + +/* SIOCSIWAUTH/SIOCGIWAUTH struct iw_param flags */ +#define IW_AUTH_INDEX 0x0FFF +#define IW_AUTH_FLAGS 0xF000 +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/get to; value will be read/written to + * struct iw_param value field) */ +#define IW_AUTH_WPA_VERSION 0 +#define IW_AUTH_CIPHER_PAIRWISE 1 +#define IW_AUTH_CIPHER_GROUP 2 +#define IW_AUTH_KEY_MGMT 3 +#define IW_AUTH_TKIP_COUNTERMEASURES 4 +#define IW_AUTH_DROP_UNENCRYPTED 5 +#define IW_AUTH_80211_AUTH_ALG 6 + + /****************************** TYPES ******************************/ /* --------------------------- SUBTYPES --------------------------- */ @@ -507,6 +602,75 @@ struct iw_quality high; /* High threshold */ }; +/* + * Optional data for scan request (MLME-SCAN.request) + */ +struct iw_scan_req +{ + __u8 bss_type; /* IW_MODE_AUTO (= Both), IW_MODE_ADHOC, or + * IW_MODE_INFRA */ + __u8 scan_type; /* IW_SCAN_TYPE_{ACTIVE,PASSIVE} */ + __u8 ssid_len; + __u8 num_channels; /* num entries in channel_list; + * 0 = scan all allowed channels */ + struct sockaddr bssid; /* ff:ff:ff:ff:ff:ff for broadcast BSSID or + * individual address of a specific BSS */ + /* Use this SSID if IW_SCAN_THIS_ESSID flag is used instead of using + * the current SSID. This allows scan requests for specific SSID + * without having to change the current SSID and potentially breaking + * the current association. */ + __u8 ssid[IW_ESSID_MAX_SIZE]; + __u32 probe_delay; /* delay in usec prior to transmitting + * ProbeReq */ + __u32 min_channel_time; /* in TU, >= probe_delay */ + __u32 max_channel_time; /* in TU, >= min_channel_time */ + struct iw_freq channel_list[IW_MAX_FREQUENCIES]; +}; + +/* + * Extended data structure for get/set encoding (this is used with + * SIOCSIWENCODEEXT/SIOCGIWENCODEEXT. struct iw_point and IW_ENCODE_* + * flags are used in the same way as with SIOCSIWENCODE/SIOCGIWENCODE and + * only the data contents changes (key data -> this structure, including + * key data). + */ +struct iw_encode_ext +{ +#define IW_ENCODE_EXT_TX_SEQ_VALID 0x00000001 +#define IW_ENCODE_EXT_RX_SEQ_VALID 0x00000002 +#define IW_ENCODE_EXT_GROUP_KEY 0x00000004 + __u32 ext_flags; + __u8 tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + __u8 rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + struct sockaddr addr; /* ff:ff:ff:ff:ff:ff for broadcast/multicast + * (group) keys or unicast address for + * individual keys */ + __u16 alg; /* IW_ENCODE_ALG_* */ + __u16 key_len; + __u8 key[0]; +}; + +/* SIOCSIWMLME data */ +struct iw_mlme +{ + __u16 cmd; /* IW_MLME_* */ + __u16 reason_code; + struct sockaddr addr; +}; + +struct iw_michaelmicfailure +{ +#define IW_MICFAILURE_KEY_ID 0x00000003 /* Key ID 0..3 */ +#define IW_MICFAILURE_GROUP 0x00000004 +#define IW_MICFAILURE_PAIRWISE 0x00000008 +#define IW_MICFAILURE_STAKEY 0x00000010 +#define IW_MICFAILURE_COUNT 0x00000060 /* 1 or 2 (0 = count not supported) + */ + __u32 flags; + struct sockaddr src_addr; + __u8 tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ +}; + /* ------------------------ WIRELESS STATS ------------------------ */ /* * Wireless statistics (used for /proc/net/wireless) @@ -685,6 +849,8 @@ struct iw_freq freq[IW_MAX_FREQUENCIES]; /* list */ /* Note : this frequency list doesn't need to fit channel numbers, * because each entry contain its channel index */ + + __u32 enc_capa; /* IW_ENC_CAPA_* bit field */ }; /* ===== net/core/wireless.c 1.15 vs edited ===== --- 1.15/net/core/wireless.c Sun Sep 28 15:29:53 2003 +++ edited/net/core/wireless.c Tue Jun 8 20:10:36 2004 @@ -189,6 +189,8 @@ }, [SIOCSIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, + .token_size = sizeof(struct iw_scan_req), + .max_tokens = 1, }, [SIOCGIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, @@ -264,6 +266,39 @@ }, [SIOCGIWPOWER - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCGIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCSIWMLME - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = sizeof(struct iw_mlme), + .max_tokens = 1, + }, + [SIOCSIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCGIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, + }, + [SIOCGIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, }, }; static const int standard_ioctl_num = (sizeof(standard_ioctl) / -- Jouni Malinen PGP id EFC895FA From hadi@cyberus.ca Tue Jun 8 20:47:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 20:47:52 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i593lQgi003479 for ; Tue, 8 Jun 2004 20:47:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BXu3j-0001aJ-53 for netdev@oss.sgi.com; Tue, 08 Jun 2004 23:47:27 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BXu3c-00076F-5v; Tue, 08 Jun 2004 23:47:20 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: jt@hpl.hp.com Cc: netdev@oss.sgi.com In-Reply-To: <20040608220109.GA24536@bougret.hpl.hp.com> References: <20040608184831.GA18462@bougret.hpl.hp.com> <1086722317.1023.18.camel@jzny.localdomain> <20040608195238.GA21089@bougret.hpl.hp.com> <1086728139.1023.71.camel@jzny.localdomain> <20040608220109.GA24536@bougret.hpl.hp.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086752809.1049.62.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jun 2004 23:46:49 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5786 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: 5469 Lines: 131 On Tue, 2004-06-08 at 18:01, Jean Tourrilhes wrote: > > According to Vladimir the wireless piece of it is different. > > i.e each DMA ring will get different 802.11 channels > > Nope they can't get to different wireless channel, unless you > have two radio modem in your hardware. If you have two radio hardware, > then you might as well present two virtual devices. Since Vladimir is not speaking up i am gonna take your word for it. > The standard 802.11e (EDCF/HCF) is mostly a modification of > the contention process on the medium, everything happens on the same > wireless channel. Vladimir's use of "channel" is confusing, but I > think he meant a virtual channel in the hardware, or something else. > > > with different backoff and contention window parameters. > > Yep. This impact the contention process. > This is similar to what was implemented in 100VG / IEEE > 802.12, but in more elaborated. so the only differentiation is on backoff and contention window parameters. In other words, higher prio will get opportunity to be more of a hog or aggressive? > > So nothing to do with the DMA process being a bottleneck. > > You were the one worried about having multiple DMA rings. > > > Help me understand this better: > > theres a wired side and a wireless side or are both send and receive > > interafacing to the air? > > This is like old coax-Ethernet, but instead of having a common > coax cable, you have a single wireless channel shared by all > stations. For more details, please look in my Wireless Howto. > Both send and receive are done on the same frequency. The > other side of the hardware plug in the PCI bus. I think i gotcha. > > Yes, but how does the CSMA figure that? Is it not from the different > > DMA rings? > > Yes. So, what the drivers need to do in the xmit handler is to > figure out what is the packet priority (probably using skb->priority > or another mechanism) and put it in the appropriate queue/ring/FIFO. > Sure this is the easy part. The hard part is below. > > Is it a FIFO or there are several DMA rings involved? If the later: > > when do you stop the netdevice (i.e call netif_stop_queue())? > > There is 4 FIFOs (or whichever number then want to configure) > in parallel. > Most likely, the FIFOs will share the same memory pool on the > card, so when a FIFO is full, most likely the other FIFOs will be full > or close to it. How do you reach such a conclusion? There maybe packets of the same priority for longs periods of time. > In theory, they could dedicate card memory to each FIFO. But, > in such case, if one FIFO is full and the other empty, it means that > the card scheduler doesn't process packets according to the netdev > scheduler. The netdev scheduler is the authoritative one, because > directly controled by the policy and the intserv/diffserv > software. Therefore you really want the card scheduler to start > draining the full FIFO before we resume sending to the other FIFOs, > otherwise the card scheduler will biased the policy netdev tries to > enforce. But then you loose sync with the qdisc level scheduling. Assume a burst of low prio packets arrive, they get drained to the low prio FIFO in the driver. It gets full and now we lock the driver. Next a burst of high prio packets come in and they cantt be sent to the driver until all low prio packets already on FIFO are sent. > So, in any case, my suggestion would be to netif_stop_queue() > as soon as one FIFO is full, and to netif_wake_queue() as soon as all > FIFO have space. This is the most simple and predictable solution. Simple, yes. Predictable or even accurate, no. Take a very simple prio based scheduling. The rules are you only process low priority packets if higher ones dont exist. It also means that higher priority packets can starve the low prio ones and that would be fine. > But, we are talking there as if the hardware was going to have > some incredibly smart scheduler across FIFOs. From my experience with > wireless MAC implementations, the behaviour will be really simplistic > (always send from the highest priority FIFO), if not totally > broken. "Always send from highest priority" is fine. Its what the default linux scheduler and the prio qdisc do. A lot of research and experienece has gone into understanding their behaviors. Perhaps you could tell users to configure such prioritization when using these NICs. > And you will probably have very little control over it in low > end cards (hardwired ?). Actually there are ethernet MACs today which have multiple DMA rings. so the general problem is not just for wireless devices. > This is why I would not trust MAC level scheduling (within a > single host), and my concern is more to avoid the card scheduler to > mess up netdev scheduling (which is a known quantity) rather than try > to find way to take advantage of it. We need to make chnages and do it properly. Your approach to use only one priority/FIFO is not sane. Of course the wireless people dont have to use it - Although that will be a mistake. I have a NIC that has two DMA channels which i plan to map to X priority levels at the the qdisc levels. > For performance reason, because of TCP behaviour, you really > want to keep packets of a flow ordered. I agree that keeping ordering > across flow in non realistic, because the point of QoS is to reorder > packet across flows. That can be handled at the TC level using policies. cheers, jamal From vkondra@mail.ru Tue Jun 8 22:57:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 22:57:13 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i595v6gi006936 for ; Tue, 8 Jun 2004 22:57:07 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 9AE65D6B5F for ; Wed, 9 Jun 2004 09:52:47 +0400 (MSD) Received: from [81.218.179.11] (port=42174 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BXvzw-000JHO-00; Wed, 09 Jun 2004 09:51:42 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: in-driver QoS Date: Wed, 9 Jun 2004 08:51:40 +0300 User-Agent: KMail/1.6.2 Cc: jt@hpl.hp.com References: <20040608184831.GA18462@bougret.hpl.hp.com> <20040608195238.GA21089@bougret.hpl.hp.com> <1086728139.1023.71.camel@jzny.localdomain> In-Reply-To: <1086728139.1023.71.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406090851.40691.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5787 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: 4017 Lines: 76 On Tuesday 08 June 2004 23:55, jamal wrote: > On Tue, 2004-06-08 at 15:52, Jean Tourrilhes wrote: > > On Tue, Jun 08, 2004 at 03:18:37PM -0400, jamal wrote: > > > Prioritization is a subset of QoS. So if 802.11e talks prioritization, > > > thats precisely what it means - QoS. > > > > Yes, it's one component of a QoS solution. But, my point is > > that on it's own, it's not enough. > > There is no mapping or exclusivity of QoS to bandwidth reservation. > The most basic QoS and most popular QoS mechanisms even on Linux is > just prioritization and nothing to do with bandwidth allocation. Correct. If you deal with bandwidth allocation, this is integrated service. Usually, diff serv used, which is just priority. BTW, in wireless QoS, bandwidth allocation present as well. Protocol is as follows: transmitter station should ask access point to establish new TSPEC (traffic specification), it get ID for this traffic, and then AP will poll station for this TSPEC, providing guranteed bandwidth, delay etc. > > > > The guy has some valid points in terms of multiple DMA rings if i > > > understood him correctly. Theres current architectural deficiencies. > > > > I don't buy that. The multiple DMA ring is not the main thing > > here, all DMA transfer share the same I/O bus to the card and share > > the same memory pool, so there is no real performance gain there. The > > I/O bnandwidth to the card is vastly superior to the medium bandwidth, > > so the DMA process will never be a bottleneck. > > According to Vladimir the wireless piece of it is different. > i.e each DMA ring will get different 802.11 channels > with different backoff and contention window parameters. > So nothing to do with the DMA process being a bottleneck. > > Help me understand this better: > theres a wired side and a wireless side or are both send and receive > interafacing to the air? > All on wireless. > > The real benefit is that the contention on the medium is > > prioritised (between contenting nodes). The contention process (CSMA, > > backoff, and all the jazz) will give a preference to stations with > > packet of the highest priority compared to stations wanting to send > > packet of lower priorities. To gain advantage of that, you only need > > to assign your packet the right priority at the driver level, and the > > CSMA will send it appropriately. > > Yes, but how does the CSMA figure that? Is it not from the different > DMA rings? > > > With respect to the 4 different hardware queue, you should see > > them only as an extension of the netdev queues. Basically, you just > > have a pipeline between the scheduler and the MAC which is almost a > > FIFO, but not exactly a FIFO. Those queues may do packet reordering > > between themselves, based on priorities. But at the end of the day > > they are only going to send what the scheduler is feeding them, and > > every packet the scheduler pass to those queues is eventually sent, so > > they are totally slave to the scheduler. > > Is it a FIFO or there are several DMA rings involved? If the later: > when do you stop the netdevice (i.e call netif_stop_queue())? You hit the problem. Due to single queue, I can't provide separate back pressure for different access categories. What I do now, I do some internal buffering and netif_stop_queue() when total number of packets (or bytes) exceed some threshold. Of course, with watermarks to fight jitter. Let's consider real example. Some application do FTP transfer, lots of data. Simultaneously, voice-over-IP connection invoked. Now question is: how to assure voice quality? Accordingly to TGe, voice is send either with high priority, or in TSPEC. If we will send all packets with high priority, we will hit ourselves. If we can't provide some back pressure for low priority traffic, it will block voice packets, since some moment you should netif_stop_queue(). Ideal would be if I can call netif_stop_queue(id), separately for each id. I will send explanation for TGe in separate mail From joe.andonieh@intel.com Tue Jun 8 23:23:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 23:24:00 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i596Ndgi007809 for ; Tue, 8 Jun 2004 23:23:40 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i596Oets026555; Wed, 9 Jun 2004 06:24:40 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i596NqXI028364; Wed, 9 Jun 2004 06:24:11 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004060909232525366 ; Wed, 09 Jun 2004 09:23:25 +0300 Received: from hasmsx402.ger.corp.intel.com ([143.185.63.156]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 09:23:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC: Linux wireless extensions and WPA support Date: Wed, 9 Jun 2004 09:23:23 +0300 Message-ID: <386CBF9421521B41835E2BF21BEF80B8968D33@hasmsx402.ger.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: Linux wireless extensions and WPA support Thread-Index: AcRN1GNaSu5dxpCMTaC5NGIJecwZqQAEU6mQ From: "Andonieh, Joe" To: "Jouni Malinen" , "Jean Tourrilhes" Cc: X-OriginalArrivalTime: 09 Jun 2004 06:23:25.0180 (UTC) FILETIME=[4531E3C0:01C44DEA] 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 i596Ndgi007809 X-archive-position: 5788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joe.andonieh@intel.com Precedence: bulk X-list: netdev Content-Length: 14577 Lines: 443 Hi Jouni Thinking about access point we need a way to set more than one cipher suite for the pairwise cipher list (for example mixed mode, which have both TKIP and CCMP users. Another aspect is an AP that wants to support more than one mode of operation, for example; advertise both WPA and RSN IE, or both WPA .1X and WPA PSK? From the Client Perspective; isn't it better Idea for the station decide or match an access point to connect with depending on the pairwise cipher only? For example a client that supports CCMP can connect to both access point where each one may be working in different mode, WPA -- CCMP as both pair wise and group ciphers or with an AP in mixed mode which have CCMP as pairwise and TKIP as groupcast cipher. Maybe my concerns are already solved and the API already answer them but I still don't know how to use it :-( I appreciate your explanation. Thanks Joe -----Original Message----- From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Jouni Malinen Sent: Wednesday, June 09, 2004 6:46 AM To: Jean Tourrilhes Cc: netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support On Mon, Jun 07, 2004 at 05:26:59PM -0700, Jean Tourrilhes wrote: > Actually, I don't like the extension of SIOC*IWENCODE. This > ioctl is already messy/complex enough as it is, and I think we would > benefit greatly in separating the two code paths, therefore using a > new iotcl for it. It's not like we are short of ioctls. OK. > The extension of SIOCSIWSCAN was always something desired, but > I never got sure of which way it was supposed to be done (look at the > unused IW_SCAN_* flags in wireless.h). > Do you think that ESSID is the only request filter that is > worthwhile ? Another option would be to allow an "iwevent" structure > allow to specify any kind of filter. Yes, there are other parameters that may be useful at some point. Actually, IEEE 802.11 specifies this list as parameters to MLME-SCAN.request and I changed struct iw_scan_req to include all the parameters. I would assume many drivers would not include some of the timing values, but at least this should cover all cases mentioned in the standard. > It took me a while to understand how this one is supposed to > works (which means that it may need better documentation). It's a > sub-ioctl kind of thing, right ? The SET accept two 32 bit integers, > the GET accept one and return one. sub-ioctl kind, but in that way.. I agree on the lack of documentation part. > You current definition doesn't work, because you are using > IW_HEADER_TYPE_PARAM that carry only a single 32bit integer. There are > two solutions. The first is fit the IW_AUTH_INDEX in the 16 bits of > iw_param->flags. The second is to use IW_HEADER_TYPE_UINT. struct iw_param has 16-bit flags field and my definition was trying to make it clear that that was indeed used for the IW_AUTH_* index numbers. In other words, I was using the first solution you list here. I added some more explicit text to make this clear. > Also, all the constant used for this command should have the > IW_AUTH_* prefix (IW_CIPHER_NONE => IW_AUTH_CIPHER_NONE), so that we > can see clearly that they apply to this command. I would even go > futher and have common prefixes between request and values : OK. > I think that "supported_feature" is too generic a name for > what you are using it now. As there are other "supported_feature" type > of fields in iw_range (pm_capa, txpower_capa, retry_capa), I would > suggest to use a more descriptive name, such as "enc_features" or > "enc_capa". My bad.. I didn't look at existing fields in struct iw_range and I didn't even remember that I have actually used those before ;-). Changed to enc_capa to match with existing fields. > > +/* IEEE 802.11 MLME requests */ > > +#define SIOCSIWMLME 0x8B30 /* request MLME operation */ > > I don't see a struct for it, so I assume the format of that is > defined somewhere in the 802.11 spec ? May be worth documenting where > to look for it. struct iw_mlme (and yes, it is based on IEEE 802.11, but does not include all parameters for all possible MLME requests). > I hope I did not sound too "picky", but I hope that my > suggestion are not too difficult to implement while adding some > value. Tell me what you think ;-) Thanks for all comments. That was not at all picky; I think I agreed with everything. Here's an updated version of the patch (again, not yet tested, so not ready to be applied). Please let me know if I missed something. ===== include/linux/wireless.h 1.9 vs edited ===== --- 1.9/include/linux/wireless.h Fri Apr 16 13:56:10 2004 +++ edited/include/linux/wireless.h Tue Jun 8 20:43:09 2004 @@ -1,7 +1,7 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 6.8.04 * * Authors : Jean Tourrilhes - HPL - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,19 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * ---------- + * - Add support for WPA/WPA2 + * - Add extended encoding configuration (SIOCSIWENCODEEXT and + * SIOCGIWENCODEEXT) + * - Add SIOCSIWGENIE/SIOCGIWGENIE + * - Add SIOCSIWMLME + * - Add struct iw_range bit field for supported encoding capabilities + * - Add optional parameter structure for SIOCSIWSCAN + * - Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA + * related parameters (extensible up to 4096 parameter values) + * - Add wireless events: IWEVWPAIE, IWEVRSNIE, IWEVMICHAELMICFAILURE */ /**************************** CONSTANTS ****************************/ @@ -249,6 +262,22 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +/* Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WME) */ +#define SIOCSIWGENIE 0x8B2E /* set generic IE */ +#define SIOCGIWGENIE 0x8B2F /* get generic IE */ + +/* IEEE 802.11 MLME requests */ +#define SIOCSIWMLME 0x8B30 /* request MLME operation; uses + * struct iw_scan_req */ + +/* Authentication mode parameters */ +#define SIOCSIWAUTH 0x8B31 /* set authentication mode params */ +#define SIOCGIWAUTH 0x8B32 /* get authentication mode params */ + +/* Extended version of encoding configuration */ +#define SIOCSIWENCODEEXT 0x8B33 /* set encoding token & mode */ +#define SIOCGIWENCODEEXT 0x8B34 /* get encoding token & mode */ + /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ /* These 16 ioctl are wireless device private. @@ -290,6 +319,11 @@ #define IWEVCUSTOM 0x8C02 /* Driver specific ascii string */ #define IWEVREGISTERED 0x8C03 /* Discovered a new node (AP mode) */ #define IWEVEXPIRED 0x8C04 /* Expired a node (AP mode) */ +#define IWEVWPAIE 0x8C05 /* WPA IE (scan results) */ +#define IWEVRSNIE 0x8C06 /* RSN IE (WPA2) (scan results) */ +#define IWEVMICHAELMICFAILURE 0x8C07 /* Michael MIC failure + * (struct iw_michaelmicfailure) + */ #define IWEVFIRST 0x8C00 @@ -370,6 +404,33 @@ #define IW_ENCODE_NOKEY 0x0800 /* Key is write only, so not present */ #define IW_ENCODE_TEMP 0x0400 /* Temporary key */ +#define IW_ENCODE_SEQ_MAX_SIZE 8 + +#define IW_ENCODE_ALG_NONE 0 +#define IW_ENCODE_ALG_WEP 1 +#define IW_ENCODE_ALG_TKIP 2 +#define IW_ENCODE_ALG_CCMP 3 + +/* IW_AUTH_WPA_VERSION values */ +#define IW_AUTH_WPA_VERSION_DISABLED 0 +#define IW_AUTH_WPA_VERSION_WPA 1 +#define IW_AUTH_WPA_VERSION_WPA2 2 + +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values */ +#define IW_AUTH_CIPHER_NONE 0 +#define IW_AUTH_CIPHER_WEP40 1 +#define IW_AUTH_CIPHER_TKIP 2 +#define IW_AUTH_CIPHER_CCMP 4 +#define IW_AUTH_CIPHER_WEP104 5 + +/* IW_AUTH_KEY_MGMT values */ +#define IW_AUTH_KEY_MGMT_802_1X 1 +#define IW_AUTH_KEY_MGMT_PSK 2 + +/* IW_AUTH_80211_AUTH_ALG values (bit field) */ +#define IW_AUTH_ALG_OPEN_SYSTEM 0x00000001 +#define IW_AUTH_ALG_SHARED_KEY 0x00000002 + /* Power management flags available (along with the value, if any) */ #define IW_POWER_ON 0x0000 /* No details... */ #define IW_POWER_TYPE 0xF000 /* Type of parameter */ @@ -412,12 +473,46 @@ #define IW_SCAN_THIS_MODE 0x0020 /* Scan only this Mode */ #define IW_SCAN_ALL_RATE 0x0040 /* Scan all Bit-Rates */ #define IW_SCAN_THIS_RATE 0x0080 /* Scan only this Bit-Rate */ + +/* struct iw_scan_req scan_type */ +#define IW_SCAN_TYPE_ACTIVE 0 +#define IW_SCAN_TYPE_PASSIVE 1 + /* Maximum size of returned data */ #define IW_SCAN_MAX_DATA 4096 /* In bytes */ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Generic information element */ +#define IW_GENERIC_IE_MAX 256 + +/* MLME requests (SIOCSIWMLME / struct iw_mlme) */ +#define IW_MLME_DEAUTH 0 +#define IW_MLME_DISASSOC 1 + +/* Bit field values for enc_capa in struct iw_range */ +#define IW_ENC_CAPA_WPA 0x00000001 +#define IW_ENC_CAPA_WPA2 0x00000002 +#define IW_ENC_CAPA_CIPHER_TKIP 0x00000004 +#define IW_ENC_CAPA_CIPHER_CCMP 0x00000008 + +/* SIOCSIWAUTH/SIOCGIWAUTH struct iw_param flags */ +#define IW_AUTH_INDEX 0x0FFF +#define IW_AUTH_FLAGS 0xF000 +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/get to; value will be read/written to + * struct iw_param value field) */ +#define IW_AUTH_WPA_VERSION 0 +#define IW_AUTH_CIPHER_PAIRWISE 1 +#define IW_AUTH_CIPHER_GROUP 2 +#define IW_AUTH_KEY_MGMT 3 +#define IW_AUTH_TKIP_COUNTERMEASURES 4 +#define IW_AUTH_DROP_UNENCRYPTED 5 +#define IW_AUTH_80211_AUTH_ALG 6 + + /****************************** TYPES ******************************/ /* --------------------------- SUBTYPES --------------------------- */ @@ -507,6 +602,75 @@ struct iw_quality high; /* High threshold */ }; +/* + * Optional data for scan request (MLME-SCAN.request) + */ +struct iw_scan_req +{ + __u8 bss_type; /* IW_MODE_AUTO (= Both), IW_MODE_ADHOC, or + * IW_MODE_INFRA */ + __u8 scan_type; /* IW_SCAN_TYPE_{ACTIVE,PASSIVE} */ + __u8 ssid_len; + __u8 num_channels; /* num entries in channel_list; + * 0 = scan all allowed channels */ + struct sockaddr bssid; /* ff:ff:ff:ff:ff:ff for broadcast BSSID or + * individual address of a specific BSS */ + /* Use this SSID if IW_SCAN_THIS_ESSID flag is used instead of using + * the current SSID. This allows scan requests for specific SSID + * without having to change the current SSID and potentially breaking + * the current association. */ + __u8 ssid[IW_ESSID_MAX_SIZE]; + __u32 probe_delay; /* delay in usec prior to transmitting + * ProbeReq */ + __u32 min_channel_time; /* in TU, >= probe_delay */ + __u32 max_channel_time; /* in TU, >= min_channel_time */ + struct iw_freq channel_list[IW_MAX_FREQUENCIES]; +}; + +/* + * Extended data structure for get/set encoding (this is used with + * SIOCSIWENCODEEXT/SIOCGIWENCODEEXT. struct iw_point and IW_ENCODE_* + * flags are used in the same way as with SIOCSIWENCODE/SIOCGIWENCODE and + * only the data contents changes (key data -> this structure, including + * key data). + */ +struct iw_encode_ext +{ +#define IW_ENCODE_EXT_TX_SEQ_VALID 0x00000001 +#define IW_ENCODE_EXT_RX_SEQ_VALID 0x00000002 +#define IW_ENCODE_EXT_GROUP_KEY 0x00000004 + __u32 ext_flags; + __u8 tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + __u8 rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + struct sockaddr addr; /* ff:ff:ff:ff:ff:ff for broadcast/multicast + * (group) keys or unicast address for + * individual keys */ + __u16 alg; /* IW_ENCODE_ALG_* */ + __u16 key_len; + __u8 key[0]; +}; + +/* SIOCSIWMLME data */ +struct iw_mlme +{ + __u16 cmd; /* IW_MLME_* */ + __u16 reason_code; + struct sockaddr addr; +}; + +struct iw_michaelmicfailure +{ +#define IW_MICFAILURE_KEY_ID 0x00000003 /* Key ID 0..3 */ +#define IW_MICFAILURE_GROUP 0x00000004 +#define IW_MICFAILURE_PAIRWISE 0x00000008 +#define IW_MICFAILURE_STAKEY 0x00000010 +#define IW_MICFAILURE_COUNT 0x00000060 /* 1 or 2 (0 = count not supported) + */ + __u32 flags; + struct sockaddr src_addr; + __u8 tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */z` +}; + /* ------------------------ WIRELESS STATS ------------------------ */ /* * Wireless statistics (used for /proc/net/wireless) @@ -685,6 +849,8 @@ struct iw_freq freq[IW_MAX_FREQUENCIES]; /* list */ /* Note : this frequency list doesn't need to fit channel numbers, * because each entry contain its channel index */ + + __u32 enc_capa; /* IW_ENC_CAPA_* bit field */ }; /* ===== net/core/wireless.c 1.15 vs edited ===== --- 1.15/net/core/wireless.c Sun Sep 28 15:29:53 2003 +++ edited/net/core/wireless.c Tue Jun 8 20:10:36 2004 @@ -189,6 +189,8 @@ }, [SIOCSIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, + .token_size = sizeof(struct iw_scan_req), + .max_tokens = 1, }, [SIOCGIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, @@ -264,6 +266,39 @@ }, [SIOCGIWPOWER - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCGIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCSIWMLME - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = sizeof(struct iw_mlme), + .max_tokens = 1, + }, + [SIOCSIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCGIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, + }, + [SIOCGIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, }, }; static const int standard_ioctl_num = (sizeof(standard_ioctl) / -- Jouni Malinen PGP id EFC895FA From rl@hellgate.ch Tue Jun 8 23:55:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jun 2004 23:55:38 -0700 (PDT) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i596tYgi008791 for ; Tue, 8 Jun 2004 23:55:34 -0700 Received: from k3.hellgate.ch (81.62.85.19) by mail2.bluewin.ch (Bluewin AG 7.0.028) id 40A46896002BE8E6; Mon, 7 Jun 2004 11:48:32 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 47715471EE2; Mon, 7 Jun 2004 13:48:32 +0200 (CEST) Date: Mon, 7 Jun 2004 13:48:32 +0200 From: Roger Luethi To: David Dillow Cc: Jeff Garzik , Andrew Morton , Netdev Subject: Re: [0/3] mc_filter on big-endian arch Message-ID: <20040607114832.GA32569@k3.hellgate.ch> References: <20040606165322.GA13247@k3.hellgate.ch> <1086575392.4731.9.camel@ori.thedillows.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086575392.4731.9.camel@ori.thedillows.org> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1813 Lines: 50 On Sun, 06 Jun 2004 22:29:52 -0400, David Dillow wrote: > I think typhoon's OK -- I calculate the filter on the host, and then do > a cpu_to_le32() on the final values, since the processor on the NIC is > in little-endian mode. > > However, I've never tested it. I'll be happy to do so, if someone will > point me to appropriate code -- I've got an Ultra5 as well, so I can > test both big and little endian machines. Otherwise, I'll test it when I > get around to writing something, or someone reports a bug. :) Warning: This is a very basic functionality test using standard Linux tools. Some existing multicast problems are detected by this (if you screw up the endianness of the filter hash, you will know :-)). Others are not. Multicast Driver Testing Quick How-To ===================================== Make sure the host you are testing replies to broadcasts: target# cat /proc/sys/net/ipv4/icmp_echo_ignore_all 0 target# cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 0 Our test packets need to go to the target host, so either have a route or use ping "-r -I " option: tester# route add -net 224.0.0.0 netmask 240.0.0.0 eth0 Since every multicast capable host interface joins 224.0.0.1, you can already ping your target: tester# ping -r -I eth0 -t 1 -c 2 224.0.0.1 Your target host should answer this (so may your tester, depending on your setup). We haven't joined the next group yet, so there should be no answer: tester# ping -r -I eth0 -t 1 -c 2 224.1.1.1 Use packet sniffer to confirm that target is not seeing the request (use -p option for tcpdump or tethereal to prevent promiscuous mode) Now join the group: target# ip maddr add 01:00:5e:01:01:01 dev eth0 tester# ping -r -I eth0 -t 1 -c 2 224.1.1.1 Use packet sniffer to confirm that target is seeing the request now. From vkondra@mail.ru Wed Jun 9 00:47:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 00:47:50 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i597lRgi018836 for ; Wed, 9 Jun 2004 00:47:28 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id C6FE3111878 for ; Wed, 9 Jun 2004 10:37:24 +0400 (MSD) Received: from [81.218.179.11] (port=48742 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BXwhA-000GbF-00 for netdev@oss.sgi.com; Wed, 09 Jun 2004 10:36:22 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: TGe (QoS in wireless) Date: Wed, 9 Jun 2004 09:36:16 +0300 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: <200406090936.16943.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5790 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: 2220 Lines: 57 I will give short overview for TGe. TGe is working group in IEEE, who is working on QoS for 802.11 wireless network. This work is close to completion, final draft will be voted and become standard shortly. Next generation of wireless cards will support TGe. Now, to the business. Single radio channel used. There are 2 access disciplines: - EDCA, which is CSCA, or contention based. 4 AC (access categories) exist, they differ by channel access parameters. Parameters include backoff, contention window and TXOP (more on this later). Parameters are set by AP and may be changed during operation. - HCCA, which is contention free access. AP (access point) gives TXOP directly to each STA, deciding who will speak. TXOP stands for transmitt opportunity. When each AC gets access to the channel, it is allowed to do burst (without backoff) for TXOP period, which is several ms. Traffic classified into 16 categories, or TID. Each packet get its TID. TID 0-7 get mapped statically to 4 AC, roughly it corresponds to TOS bits. TID 8-15 mapped to TSPECs. TSPEC is traffic specification, which consist of bandwidth specification (throughput, delay etc. - see RSVP for example) and TCLAS - classifiers passed to AP side to classify packets. TSPEC may be for HCCA or EDCA access. In case of HCCA, it get simple periodic schedule, set by AP. AP will poll STA accordingly to this schedule, and Tx to STA accordingly to schedule. In case of EDCA, it is just bandwidth allocation control. Admission. AP may enforce admission control for some (actually, 2 high prio) AC, prohibiting its normal operation and requiring TSPEC establishment in order to use these categories. I did not touched B-ACK (block ack), local broadcast, and DLP (direct link protocol) that deals nothing with QoS. ----------below is my interpretation----------- This leads to the following channel model : - single Rx channel - 4 FIFO/DMA rings, one per AC. - 1 to 8 FIFO/DMA rings for TSPEC traffic. In-NIC scheduler decides which FIFO get to the air. Time for decision is about 10 us, thus it can't be done on host. Decision is the following: - poll from AP -> TSPEC - channel is clear, random backoff expired -> AC Vladimir. From Robert.Olsson@data.slu.se Wed Jun 9 00:51:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 00:51:43 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i597pMgi019224 for ; Wed, 9 Jun 2004 00:51: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 i597pINY007899; Wed, 9 Jun 2004 09:51:18 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 6606B905BE; Wed, 9 Jun 2004 09:51:18 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16582.49526.374109.580312@robur.slu.se> Date: Wed, 9 Jun 2004 09:51:18 +0200 To: "Chris Carpinello" Cc: P@draigBrady.com, netdev@oss.sgi.com Subject: Re: e1000 w/ NAPI + SMP = 99% CPU utilization In-Reply-To: References: 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 i597pMgi019224 X-archive-position: 5791 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: 3480 Lines: 99 Chris Carpinello writes: Hello! Is seems like your network load @ ~202 Mbps gets you system into continuing polling as we see very few interrupts on your eth3. This means that rx_softirq reschedules itself do_softirq() kicks ksoftird to prevent the rx_softirq from monopolize the system. So now all the work gets accounted in ksoftird And by design ->poll is strictly serialized per device to guarantee ordering and avoid cache bouncing we only see one ksoftirq used as use only have one input device. Pdraig suggest binding to separate CPU's. This is normally a good thing but as you only have one input device it will not help. And didn't we just see a fix for ifconfig down oops? Cheers. --ro > >Padraig wrote: > >At what packet rate does it go to 100%? > > I haven't narrowed down a threshold. tcpstat reports bps=202737465 > on eth3. eth0 is a management interface (doesn't packet sniff). eth1 > and eth2 are ifconfig'd down. > > >Anyway it's not much to worry about as > >it's in polling mode. > > I'm concerned because when I ifconfig down eth3 the kernel panics. > Under high traffic loads, the box will panic as well. Here's the oops, > which is hand copied from the console: > > Oops: 0002 [#1] > SMP > CPU: 0 > EIP: 0060:[] Not tainted > EFLAGS: 00010002 (2.6.5) > EIP is at net_rx_action+0x86/0x120 > eax: 00200200 ebx: df22b0fc ecx: 0000009d edx: 00100100 > esi: df22b000 edi: c1508840 ebp: fffe4c97 esp: dff8bf78 > ds: 007b es: 007b ss: 0068 > Process ksoftirqd/0 (pid: 3, threadinfo=dff8a000 task=dff90600) > Stack: > df22b000 df8bf80 000000ec 00000001 c04f1c18 0000000a 00000246 c0126a7a > c04f1c18 dff8a000 dff8a000 dff8a000 c0126f10 c0126f95 dff90600 00000013 > dff8a000 dff93f74 00000000 c01367aa 00000000 00000003 00000000 fffffffc > Call Trace: > [] do_softirq+0xca/0xd0 > [] ksoftirqd+0x0/0xd0 > [] ksoftirqd+0x85/0xd0 > [] kthread+0xba/0xc0 > [] kthread+0x0/0xc0 > [] kernel_thread_helper+0x5/0x10 > Code: 89 42 04 89 10 8d 57 1c c7 43 04 00 02 20 00 8b 42 04 89 13 > <0> Kernel panic: Fatal exception in interrupt > In interrupt handler - not syncing > > >One thing which should help is to share > >the work across your CPUs. `cat /proc/interrupts` > >will show the interrupts for your nics. > > # cat /proc/interrupts > CPU0 CPU1 > 0: 3758655 3223347 IO-APIC-edge timer > 1: 2 7 IO-APIC-edge i8042 > 2: 0 0 XT-PIC cascade > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-level acpi > 14: 22 7 IO-APIC-edge ide0 > 16: 11 11 IO-APIC-level eth1 > 17: 5471 5475 IO-APIC-level eth0 > 18: 1790 1794 IO-APIC-level aic7xxx > 19: 15 15 IO-APIC-level aic7xxx > 20: 2 1 IO-APIC-level eth2 > 24: 1549 1349 IO-APIC-level eth3 > NMI: 0 0 > LOC: 6982002 6982001 > ERR: 0 > MIS: 0 > > >Then you can bind the interrupt to a particular CPU like: > > > >echo 1 > /proc/irq/$num/smp_affinity > >echo 2 > /proc/irq/$num/smp_affinity > >echo 4 > /proc/irq/$num/smp_affinity > >echo 8 > /proc/irq/$num/smp_affinity > > Setting the mask has no noticeable effect on ksoftirqd's > behavior. > > - Chris > > From cks@utcc.utoronto.ca Wed Jun 9 01:08:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 01:08:02 -0700 (PDT) Received: from ugw.utcc.utoronto.ca (ugw.utcc.utoronto.ca [128.100.102.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5987xgi019862 for ; Wed, 9 Jun 2004 01:07:59 -0700 Received: from localhost by ugw.utcc.utoronto.ca with SMTP id <3014>; Wed, 9 Jun 2004 04:07:52 -0400 To: netdev@oss.sgi.com Subject: [IPSEC] TCP session over ESP transport stalls after a re-keying Date: Wed, 9 Jun 2004 04:07:48 -0400 From: Chris Siebenmann Message-Id: <04Jun9.040752edt.3014@ugw.utcc.utoronto.ca> X-archive-position: 5792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cks@utcc.utoronto.ca Precedence: bulk X-list: netdev Content-Length: 3999 Lines: 77 I seem to be encountering a problem where a active TCP sessions running over an IPSEC ESP transport layer stalls out immediately after the IKE daemons involved re-key the connection. Environment: Fedora Core 2 and current 2.6.7-rc3 (from BitKeeper) kernels on both sides, using the FC2 racoon for key exchange. The SPDs are symmetric as any -P ipsec esp/transport//require ; (straight transport; there are no tunnels involved.) Racoon negociates the keys on initial startup and correctly re-keys as the key durations expire, and things like ping work throughout (although ping seems to sometimes skip a packet when racoon removes the old keys). However, a ssh session from one machine to the other running 'top' (or apparently any other data generator) will usually stall out when the racoon daemons remove the old keys after a re-keying. In the following discussion, let the machine running ssh be A (the client) and the machine ssh'd to that is running top be B (the server). According to tcpdump, at the moment of the stall almost always the last traffic was a packet from B to A (presumably a top update) followed immediately by a A to B packet (presumably the ACK for same). Sometimes this pair is in the old (still valid) keys, a few times this pair is in the newly established keys (if it happens just after the switchover). Once this happens, there seems to be no further transmissions either way (even if I wait quite a while). On B, 'netstat --inet' shows a growing send queue. On A, send and receive queues show as 0 bytes. When the stall happens, B's kernel reports: pmtu discovery on SA ESP/A key>/80646633 repeatedly. A's kernel shows no reports. (The ethernet MTUs are standard on both ends.) If one bangs on the keyboard A will send packets to B, with B usually sending back, but the 'top' display never updates and B appears to send nothing but immediate replies to A's packets. If I kill the racoon daemons, flush the SPDs, and let things sit, B eventually wakes up and starts sending to A (in clear, since there are no SPDs to dictate otherwise). The tcpdump output in this situation looks like B.ssh > A.40326: P 654520954:654522386(1432) ack 2913244198 win 11552 A.40326 > B.ssh: . ack 1432 win 62718 B.ssh > A.40326: . 1432:2864(1432) ack 1 win 11552 A.40326 > B.ssh: . ack 2864 win 62718 (And so on). If one has banged on the keyboard on A during the hang, one sees a similar pattern but eventually A wakes up and starts sending: A.40333 > B.ssh: P 1:49(48) ack 45872 win 54416 B.ssh > A.40333: . ack 49 win 11552 [...] B.ssh > A.40333: . 51568:53000(1432) ack 49 win 11552 A.40333 > B.ssh: . ack 53000 win 63008 A.40333 > B.ssh: P 49:97(48) ack 53000 win 63008 B.ssh > A.40333: P 53000:54368(1368) ack 49 win 11552 B.ssh > A.40333: . ack 97 win 11552 (All the A to B data was generated during the stall, despite the (re)transmits much later.) Unfortunately I have been unsuccessful in my attempts to build a version of tcpdump that will decrypt ESP packets, so I cannot say what is being sent & received while the SPDs are active. Please let me know if there's a better tool for this that I should be using. In case it matters, A is a SMP Pentium with an Intel 82557/8/9 using the e100 driver; B is a uniprocessor Athlon with a 3Com 3C940 using the sk98lin driver. Both are running at 100Mbits, but they're on different subnets. I would be happy to provide any further information people want. Many thanks in advance. My apologies if this is a FAQ (or if this is the wrong mailing list). - cks From P@draigBrady.com Wed Jun 9 02:01:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 02:01:12 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59918gi021166 for ; Wed, 9 Jun 2004 02:01:09 -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 i59912aq091518; Wed, 9 Jun 2004 10:01:03 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40C6D1CE.9050202@draigBrady.com> Date: Wed, 09 Jun 2004 10:01:02 +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: Chris Carpinello , netdev@oss.sgi.com Subject: Re: e1000 w/ NAPI + SMP = 99% CPU utilization References: <16582.49526.374109.580312@robur.slu.se> In-Reply-To: <16582.49526.374109.580312@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i59912aq091518 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i59918gi021166 X-archive-position: 5793 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: 910 Lines: 26 Robert Olsson wrote: > Chris Carpinello writes: > > Hello! > > Is seems like your network load @ ~202 Mbps gets you system into > continuing polling as we see very few interrupts on your eth3. > This means that rx_softirq reschedules itself do_softirq() kicks > ksoftird to prevent the rx_softirq from monopolize the system. > So now all the work gets accounted in ksoftird And by design > ->poll is strictly serialized per device to guarantee ordering and > avoid cache bouncing we only see one ksoftirq used as use only have > one input device. > > Pdraig suggest binding to separate CPU's. This is normally a good > thing but as you only have one input device it will not help. agreed. All traffic is on eth3 so you can't share it over CPUs > And didn't we just see a fix for ifconfig down oops? yep, seems like it: http://marc.theaimsgroup.com/?l=linux-netdev&m=108631346103966&w=2 Pdraig. From sneakums@zork.net Wed Jun 9 03:15:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 03:15:26 -0700 (PDT) Received: from zork.zork.net (Debian-exim@zork.zork.net [64.81.246.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59AFOgi027322 for ; Wed, 9 Jun 2004 03:15:24 -0700 Received: from sneakums by zork.zork.net with local (Exim 4.32) id 1BY079-0000Zn-CZ for netdev@oss.sgi.com; Wed, 09 Jun 2004 03:15:23 -0700 To: netdev@oss.sgi.com Subject: [TRIVIAL PATCH] include/net/tcp.h comment fix From: Sean Neakums Mail-Followup-To: netdev@oss.sgi.com Date: Wed, 09 Jun 2004 11:15:22 +0100 Message-ID: <6uy8mxghqd.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: 5794 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: 675 Lines: 18 I had a few moments' consternation trying to follow from struct tck_skb_cb back to cb[], since the struct is named sk_buff. This may well confuse other unschooled readers in the future. Against 2.6.7-rc3. --- S7-rc3/include/net/tcp.h~ 2004-05-10 09:22:40.000000000 +0100 +++ S7-rc3/include/net/tcp.h 2004-06-09 11:07:33.000000000 +0100 @@ -1139,7 +1139,7 @@ * code. We also store the host-order sequence numbers in * here too. This is 36 bytes on 32-bit architectures, * 40 bytes on 64-bit machines, if this grows please adjust - * skbuff.h:skbuff->cb[xxx] size appropriately. + * skbuff.h:sk_buff->cb[xxx] size appropriately. */ struct tcp_skb_cb { union { From hadi@cyberus.ca Wed Jun 9 04:20:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 04:20:52 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59BKlgi032754 for ; Wed, 9 Jun 2004 04:20:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BY18N-0008Q4-Pz for netdev@oss.sgi.com; Wed, 09 Jun 2004 07:20:43 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BY18K-0006VX-Sq; Wed, 09 Jun 2004 07:20:41 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, jt@hpl.hp.com In-Reply-To: <200406090851.40691.vkondra@mail.ru> References: <20040608184831.GA18462@bougret.hpl.hp.com> <20040608195238.GA21089@bougret.hpl.hp.com> <1086728139.1023.71.camel@jzny.localdomain> <200406090851.40691.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086780010.1051.106.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Jun 2004 07:20:10 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5795 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: 1712 Lines: 43 On Wed, 2004-06-09 at 01:51, Vladimir Kondratiev wrote: > > Is it a FIFO or there are several DMA rings involved? If the later: > > when do you stop the netdevice (i.e call netif_stop_queue())? > > You hit the problem. Sorry, I should have made it clear and reemphasized it a few times. I think Jean understands the issue but not its repurcassions. > Due to single queue, I can't provide separate back > pressure for different access categories. What I do now, I do some internal > buffering and netif_stop_queue() when total number of packets (or bytes) > exceed some threshold. Of course, with watermarks to fight jitter. Will work fine if you have mostly only one priority really. > Let's consider real example. Some application do FTP transfer, lots of data. > Simultaneously, voice-over-IP connection invoked. Now question is: how to > assure voice quality? Non-trivial with current setup. > Accordingly to TGe, voice is send either with high > priority, or in TSPEC. If we will send all packets with high priority, we > will hit ourselves. If we can't provide some back pressure for low priority > traffic, it will block voice packets, since some moment you should > netif_stop_queue(). > > Ideal would be if I can call netif_stop_queue(id), separately for each id. Indeed. Looking at the transmit path code it seems doable. for each dev->id you also maintain a dev->id_state. We either use skb->fwmark or skb->priority to map to the different dev->ids. The major challenge would be how to start the different queues once they are stopped. I suspect there is only tx completed interupt; i take it you can tell when each of the FIFOs is ready to swallow more packets? cheers, jamal From pragati.k@samsung.com Wed Jun 9 04:26:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 04:26:59 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59BQmgi000731 for ; Wed, 9 Jun 2004 04:26:49 -0700 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZ100F0BH4IP3@mailout3.samsung.com> for netdev@oss.sgi.com; Wed, 09 Jun 2004 20:26:42 +0900 (KST) Received: from ep_ms13_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZ100BENH4IA0@mailout3.samsung.com> for netdev@oss.sgi.com; Wed, 09 Jun 2004 20:26:42 +0900 (KST) Received: from ep_spt03 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZ100KF7H4HF3@ms13.samsung.com> for netdev@oss.sgi.com; Wed, 09 Jun 2004 20:26:42 +0900 (KST) Content-return: prohibited Date: Wed, 09 Jun 2004 11:26:33 +0000 (GMT) From: PRAGATI KUMAR DHINGRA Subject: Re :Re: in-driver QoS X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPP0VuZ2luZWVy?= To: jamal Cc: Vladimir Kondratiev , "netdev@oss.sgi.com " , "jt@hpl.hp.com " Reply-to: pragati.k@samsung.com Message-id: <6286748.1086780401662.JavaMail.weblogic@ep_app25> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040609112641660@pragati.k X-MTR: 20040609112641660@pragati.k X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-archive-position: 5796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pragati.k@samsung.com Precedence: bulk X-list: netdev Content-Length: 3160 Lines: 68 ----- Original Message ----- From: "Vladimir Kondratiev" To: ; Cc: Sent: Wednesday, June 09, 2004 11:21 AM Subject: Re: in-driver QoS > > > With respect to the 4 different hardware queue, you should see > > > them only as an extension of the netdev queues. Basically, you just > > > have a pipeline between the scheduler and the MAC which is almost a > > > FIFO, but not exactly a FIFO. Those queues may do packet reordering > > > between themselves, based on priorities. But at the end of the day > > > they are only going to send what the scheduler is feeding them, and > > > every packet the scheduler pass to those queues is eventually sent, so > > > they are totally slave to the scheduler. > > > > Is it a FIFO or there are several DMA rings involved? If the later: > > when do you stop the netdevice (i.e call netif_stop_queue())? > You hit the problem. Due to single queue, I can't provide separate back > pressure for different access categories. What I do now, I do some internal > buffering and netif_stop_queue() when total number of packets (or bytes) > exceed some threshold. Of course, with watermarks to fight jitter. > > Let's consider real example. Some application do FTP transfer, lots of data. > Simultaneously, voice-over-IP connection invoked. Now question is: how to > assure voice quality? Accordingly to TGe, voice is send either with high > priority, or in TSPEC. If we will send all packets with high priority, we > will hit ourselves. If we can't provide some back pressure for low priority > traffic, it will block voice packets, since some moment you should > netif_stop_queue(). > > Ideal would be if I can call netif_stop_queue(id), separately for each id. Two alternatives that I can think of: 1. Maintain only one queue as Jean suggested As a hypothetical example, let max queue length be 100. Given 4 priority levels (1-4 with 4 being the highest) we can define minimum and maximum threshold for number of slots for each level. Level Min Max 4 35 55 3 25 45 2 15 35 1 5 25 At any given time, we have 80 slots reserved in proprotion to the priority and a free pool of 20 slots to support whaichever level is experiencing high volume. ofcourse this scheme invalidates the assumption: > Most likely, the FIFOs will share the same memory pool on the > card, so when a FIFO is full, most likely the other FIFOs will be full > or close to it. 2. If all traffic is from a single level, dedicate entire queue to it ... If there are multiple levels, decide ration the slots ... If levels 4 and 3 are co-existing, for every 5 packets of level 4, we send 3 packets of level 3 or something like that ... As soon as a new level traffic begins, the appropriate ratio of slots in the queue are reserved for it ... They may be full, in that case we can wait for them to empty (150Mbps) or we can drop some of them and notify failure to higher layers. Regards Pragati From vda@port.imtp.ilyichevsk.odessa.ua Wed Jun 9 05:01:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 05:01:30 -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.12.10/8.12.9) with SMTP id i59Bwvgi027738 for ; Wed, 9 Jun 2004 05:00:33 -0700 Received: (qmail 23052 invoked by alias); 9 Jun 2004 11:25:43 -0000 Received: from vda@port.imtp.ilyichevsk.odessa.ua by guard by uid 80 with qmail-scanner-1.22 ( Clear:RC:1(172.16.42.177):. Processed in 0.370819 secs); 09 Jun 2004 11:25:43 -0000 Received: from unknown (HELO firebird) (172.16.42.177) by 0 (172.16.22.3) with ESMTP; 09 Jun 2004 11:25:39 -0000 Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: UDP sockets bound to ANY send answers with wrong src ip address Date: Wed, 9 Jun 2004 14:25:39 +0300 X-Mailer: KMail [version 1.4] Cc: davem@redhat.com, yoshfuji@linux-ipv6.org, pekkas@netcore.fi, jmorris@redhat.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Message-Id: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i59Bwvgi027738 X-archive-position: 5797 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: 1973 Lines: 56 I observe that UDP sockets listening on ANY send response packets with ip addr derived from ip address of interface which is used to send 'em instead of using dst ip address of client's packet. I was bitten by this with DNS and NTP. This is a test setup: {net 172.16/16}----- 172.16.22.2 [multihomed] 195.66.192.167 ----.... This is a UDP server on multihomed box: # echo test | nc -vvvnu -l -p 222 listening on [any] 222 ... connect to [172.16.22.2] from (UNKNOWN) [172.16.42.177] 333 ping sent 5, rcvd 5 : Connection refused # This is client on 172.16.42.177: # echo ping | nc -vvvnu -p 333 195.66.192.167 222 (UNKNOWN) [195.66.192.167] 222 (?) open it waits forever, never getting 'test' string from server. This is a tcpdump of this event: 13:58:00.555207 172.16.42.177.333 > 195.66.192.167.222: udp 5 (DF) 13:58:00.559849 172.16.22.2.222 > 172.16.42.177.333: udp 5 (DF) ^^^^^^^^^^^ 13:58:00.560457 172.16.42.177 > 172.16.22.2: icmp: 172.16.42.177 udp port 333 unreachable [tos 0xc0] This is why 172.16.42.177 thinks that port 333 is unreachable: # lsof -nP | grep 333 ntpd 418 root mem REG 3,4 133316 68184 /.share/usr/lib/all-lib/libreadline.so.3.0 most 7559 root txt REG 3,4 46828 24333 /.share/usr/app/most-4.9.2/bin/most nc 15085 root 3u IPv4 29381 UDP 172.16.42.177:333->195.66.192.167:222 # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ kernel does not think that 172.16.22.2.222 > 172.16.42.177.333 packet belong to this socket, and it is right imo. Test works ok if I remove -u from both netcats (i.e. TCP works). client: # uname -a Linux firebird 2.6.6-rc1-bk1 #1 Wed May 26 11:03:11 EEST 2004 i686 unknown server: # uname -a Linux oldie 2.4.22-rc2_QoS #1 Tue Nov 18 15:55:00 GMT-2 2003 i586 unknown root@oldie:/.share/home/vda# I saw this behavior on 2.6 based machines as well. -- vda From ja@ssi.bg Wed Jun 9 05:19:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 05:19:52 -0700 (PDT) Received: from l.himel.bg (IDENT:root@[213.91.247.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59CJjgi029132 for ; Wed, 9 Jun 2004 05:19:46 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.11.6/8.9.3) with ESMTP id i59CICL08028; Wed, 9 Jun 2004 15:18:12 +0300 Date: Wed, 9 Jun 2004 15:18:12 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: Denis Vlasenko cc: netdev@oss.sgi.com, , , , , , Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address In-Reply-To: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5798 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: 762 Lines: 28 Hello, On Wed, 9 Jun 2004, Denis Vlasenko wrote: > I observe that UDP sockets listening on ANY > send response packets with ip addr derived from > ip address of interface which is used to send 'em > instead of using dst ip address of client's packet. > > I was bitten by this with DNS and NTP. The problem is in the apps. You have some options: - use sockets listening on ANY and using sendmsg with IP_PKTINFO and providing the desired src IP in ipi_spec_dst - you can also create many listener sockets listening on particular src IP and to reply using the socket where the request is received, because the kernel does not know any association between request and reply packets if the listener is bound to ANY. Regards -- Julian Anastasov From yoshfuji@linux-ipv6.org Wed Jun 9 05:23:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 05:23:45 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59CNggi029519 for ; Wed, 9 Jun 2004 05:23:42 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CF0E233CE5; Wed, 9 Jun 2004 21:24:30 +0900 (JST) Date: Wed, 09 Jun 2004 21:24:30 +0900 (JST) Message-Id: <20040609.212430.123946645.yoshfuji@linux-ipv6.org> To: vda@port.imtp.ilyichevsk.odessa.ua Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, pekkas@netcore.fi, jmorris@redhat.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> References: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> 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: 5799 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: 421 Lines: 10 In article <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> (at Wed, 9 Jun 2004 14:25:39 +0300), Denis Vlasenko says: > I observe that UDP sockets listening on ANY > send response packets with ip addr derived from > ip address of interface which is used to send 'em > instead of using dst ip address of client's packet. use IP_PKTINFO when responding the client. --yoshfuji From kleptog@svana.org Wed Jun 9 05:26:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 05:26:07 -0700 (PDT) Received: from svana.org (mail@svana.org [203.20.62.76]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59CQ0gi029861 for ; Wed, 9 Jun 2004 05:26:03 -0700 Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 1BY24F-0004P6-00; Wed, 09 Jun 2004 22:20:31 +1000 Date: Wed, 9 Jun 2004 22:20:30 +1000 From: Martijn van Oosterhout To: Denis Vlasenko Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, yoshfuji@linux-ipv6.org, pekkas@netcore.fi, jmorris@redhat.com, linux-kernel@vger.kernel.org Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address Message-ID: <20040609122030.GA14854@svana.org> Reply-To: Martijn van Oosterhout References: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> 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: 5800 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: 1892 Lines: 55 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2004 at 02:25:39PM +0300, Denis Vlasenko wrote: > I observe that UDP sockets listening on ANY > send response packets with ip addr derived from > ip address of interface which is used to send 'em > instead of using dst ip address of client's packet. >=20 > I was bitten by this with DNS and NTP. This is the responsibility of the program. Unless the UDP packet is bound to a particular address, or the program specifies an IP, the kernel will pick one. For this reason both the BIND and NTP daemons open a socket for each interface so they can control this. netstat on my machine shows: udp 0 0 192.168.1.225:123 0.0.0.0:* = =20 udp 0 0 127.0.0.1:123 0.0.0.0:* = =20 udp 0 0 0.0.0.0:123 0.0.0.0:* = =20 for the NTP server. The DNS has similar machanism. Remember, UDP doesn't involve connections, so there is no concept of "replying" to a packet, the program has to manage that itself. In your example, if you tell netcat which address to bind to, it will work. Hope this helps, --=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. --yrj/dFKFPuw6o+aM 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 iD8DBQFAxwCOY5Twig3Ge+YRAuhNAJ9nPZoSBpqFJ6VKJeBEfZ/mGa1R2wCbBfzd crXiVHsXqOnJ/gXHkGju+xM= =vPAq -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From pp@ee.oulu.fi Wed Jun 9 05:29:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 05:29:11 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59CT7gi030251 for ; Wed, 9 Jun 2004 05:29:08 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.11/8.12.11) with ESMTP id i59CT5sT022185; Wed, 9 Jun 2004 15:29:05 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i59CT5hV012979; Wed, 9 Jun 2004 15:29:05 +0300 (EEST) Date: Wed, 9 Jun 2004 15:29:05 +0300 From: Pekka Pietikainen To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040609122905.GA12715@ee.oulu.fi> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> <20040605131923.232f8950.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20040605131923.232f8950.davem@redhat.com> User-Agent: Mutt/1.4.2i X-archive-position: 5801 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: 4251 Lines: 141 On Sat, Jun 05, 2004 at 01:19:23PM -0700, David S. Miller wrote: > On Sat, 5 Jun 2004 23:06:44 +0300 > Pekka Pietikainen wrote: > > > + if(virt_to_bus(skb->data) + skb->len > B44_PCI_DMA_MAX) { > > You can't use this non-portable interface, you have to: > > 1) pci_map the data > 2) test the dma_addr_t returned Ok, fixed. Certainly not ideal, but should fix things for those with problems (ie. running the 4G4G patch) and work as before for everyone else. --- linux-2.6.6-1.422/drivers/net/b44.h.4g4g 2004-06-09 15:19:21.315565880 +0300 +++ linux-2.6.6-1.422/drivers/net/b44.h 2004-06-09 15:19:29.787277984 +0300 @@ -503,6 +503,7 @@ struct ring_info *rx_buffers; struct ring_info *tx_buffers; + unsigned char *tx_bufs; u32 dma_offset; u32 flags; @@ -534,7 +535,7 @@ struct pci_dev *pdev; struct net_device *dev; - dma_addr_t rx_ring_dma, tx_ring_dma; + dma_addr_t rx_ring_dma, tx_ring_dma,tx_bufs_dma; u32 rx_pending; u32 tx_pending; --- linux-2.6.6-1.422/drivers/net/b44.c.4g4g 2004-06-09 15:19:16.334323144 +0300 +++ linux-2.6.6-1.422/drivers/net/b44.c 2004-06-09 15:22:48.754030440 +0300 @@ -67,6 +67,7 @@ #define NEXT_TX(N) (((N) + 1) & (B44_TX_RING_SIZE - 1)) #define RX_PKT_BUF_SZ (1536 + bp->rx_offset + 64) +#define TX_PKT_BUF_SZ (B44_MAX_MTU + ETH_HLEN + 8) /* minimum number of free TX descriptors required to wake up TX process */ #define B44_TX_WAKEUP_THRESH (B44_TX_RING_SIZE / 4) @@ -82,6 +83,12 @@ static int b44_debug = -1; /* -1 == use B44_DEF_MSG_ENABLE as value */ +/* Hardware bug work-around, the chip seems to be unable to do PCI DMA + to anything above 1GB :-( */ + +#define B44_DMA_MASK 0x3fffffff +static int b44_use_bounce_buffers = 0; + static struct pci_device_id b44_pci_tbl[] = { { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, @@ -634,7 +641,13 @@ src_map = &bp->rx_buffers[src_idx]; dest_idx = dest_idx_unmasked & (B44_RX_RING_SIZE - 1); map = &bp->rx_buffers[dest_idx]; - skb = dev_alloc_skb(RX_PKT_BUF_SZ); + + if(!b44_use_bounce_buffers) { + skb = dev_alloc_skb(RX_PKT_BUF_SZ); + } else { + /* Sigh... */ + skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_DMA); + } if (skb == NULL) return -ENOMEM; @@ -919,7 +932,12 @@ entry = bp->tx_prod; mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE); - + if(b44_use_bounce_buffers && mapping+len > B44_DMA_MASK) { + pci_unmap_single(bp->pdev, mapping, len,PCI_DMA_TODEVICE); + memcpy(bp->tx_bufs+entry*TX_PKT_BUF_SZ,skb->data,skb->len); + skb->data=bp->tx_bufs+entry*TX_PKT_BUF_SZ; + mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE); + } bp->tx_buffers[entry].skb = skb; pci_unmap_addr_set(&bp->tx_buffers[entry], mapping, mapping); @@ -1066,6 +1084,11 @@ bp->tx_ring, bp->tx_ring_dma); bp->tx_ring = NULL; } + if (bp->tx_bufs) { + pci_free_consistent(bp->pdev, B44_TX_RING_SIZE * TX_PKT_BUF_SZ, + bp->tx_bufs, bp->tx_bufs_dma); + bp->tx_bufs = NULL; + } } /* @@ -1088,6 +1111,13 @@ goto out_err; memset(bp->tx_buffers, 0, size); + if(b44_use_bounce_buffers) { + size = B44_TX_RING_SIZE * TX_PKT_BUF_SZ; + bp->tx_bufs = pci_alloc_consistent(bp->pdev, size, &bp->tx_bufs_dma); + if (!bp->tx_bufs) + goto out_err; + memset(bp->tx_bufs, 0, size); + } size = DMA_TABLE_BYTES; bp->rx_ring = pci_alloc_consistent(bp->pdev, size, &bp->rx_ring_dma); if (!bp->rx_ring) @@ -1727,12 +1757,26 @@ pci_set_master(pdev); - err = pci_set_dma_mask(pdev, (u64) 0xffffffff); +#ifdef CONFIG_X86_4G + /* XXX Only needs to be set if > 1GB of physical memory, so + this check could be smarted */ + b44_use_bounce_buffers=1; +#endif + err = pci_set_dma_mask(pdev, (u64) B44_DMA_MASK); if (err) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); goto err_out_free_res; } + + if(b44_use_bounce_buffers) { + err = pci_set_consistent_dma_mask(pdev, (u64) B44_DMA_MASK); + if (err) { + printk(KERN_ERR PFX "No usable DMA configuration, " + "aborting.\n"); + goto err_out_free_res; + } + } b44reg_base = pci_resource_start(pdev, 0); b44reg_len = pci_resource_len(pdev, 0); -- Pekka Pietikainen From felipe_alfaro@linuxmail.org Wed Jun 9 06:06:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 06:07:04 -0700 (PDT) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59D6fgi009151 for ; Wed, 9 Jun 2004 06:06:48 -0700 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 24F8F42E3D; Wed, 9 Jun 2004 15:06:26 +0200 (CEST) Subject: Re: 2.6.7-rc3: waiting for eth0 to become free From: Felipe Alfaro Solana To: Stephen Hemminger Cc: NetDev Mailinglist , Kernel Mailinglist In-Reply-To: <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> Content-Type: text/plain Date: Wed, 09 Jun 2004 15:06:30 +0200 Message-Id: <1086786391.1692.4.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 (1.5.9.1-2) Content-Transfer-Encoding: 7bit X-archive-position: 5802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: netdev Content-Length: 8971 Lines: 295 On Tue, 2004-06-08 at 14:02 -0700, Stephen Hemminger wrote: > On Tue, 08 Jun 2004 22:09:29 +0200 > Felipe Alfaro Solana wrote: > > > On Tue, 2004-06-08 at 12:42 -0700, Stephen Hemminger wrote: > > > On Tue, 08 Jun 2004 21:18:30 +0200 > > > Felipe Alfaro Solana wrote: > > > > > > > Hi! > > > > > > > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > > > > "cardctl eject" so the system won't freeze when resuming. "cardctl > > > > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > > > > network sockets opened (for example, Evolution mantaining a connection > > > > against an IMAP server): the card is ejected (well, not physically), > > > > even when there are ESTABLISHED connections. > > > > > > > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > > > > holds any socket open. After a while the "unregister_netdevice: waiting > > > > for eth0 to become free" message starts appearing on the kernel message > > > > ring. The only apparent solution is killing that program, ejecting the > > > > card from its slot and wait until 3c59x.o usage count reaches zero. > > > > > > > > Can someone tell me what's going on here? > > > > Thank you very much. > > > > > > What protocols are you running? Is IPV6 loaded? > > > > I'm using IPv4, IPv6 and IPSec ESP with AES/CBC. > > Do you want .config? > > Not really, could you see if it is an IPv6 vs IPSec problem by not running/loading > one or the other. > > What is happening is that some subsystem is holding a reference to the device (calling dev_hold()) > but not cleaning up (calling dev_put). It can be a hard to track which of the many > things routing, etc are not being cleared properly. Look for routes that still > get stuck (ip route) and neighbor cache entries. Most of these end up being > protocol bugs. I think you were pointing me in the right direction. I've found the following changes to net/ipv4/route.c and net/ipv6/route.c between 2.6.7-rc2-mm2 and 2.6.7-rc3-mm1: diff -uNr linux-2.6.7-rc2-mm2/net/ipv4/route.c linux-2.6.7-rc3-mm1/net/ ipv4/route.c --- linux-2.6.7-rc2-mm2/net/ipv4/route.c 2004-06-09 13:15:46.000000000 +0200 +++ linux-2.6.7-rc3-mm1/net/ipv4/route.c 2004-06-09 12:55:19.000000000 +0200 @@ -1040,6 +1040,8 @@ rt->u.dst.child = NULL; if (rt->u.dst.dev) dev_hold(rt->u.dst.dev); + if (rt->idev) + in_dev_hold(rt->idev); rt->u.dst.obsolete = 0; rt->u.dst.lastuse = jiffies; rt->u.dst.path = &rt->u.dst; @@ -1321,11 +1323,17 @@ { struct rtable *rt = (struct rtable *) dst; struct inet_peer *peer = rt->peer; + struct in_device *idev = rt->idev; if (peer) { rt->peer = NULL; inet_putpeer(peer); } + + if (idev) { + rt->idev = NULL; + in_dev_put(idev); + } } static void ipv4_link_failure(struct sk_buff *skb) @@ -1339,8 +1347,10 @@ dst_set_expires(&rt->u.dst, 0); } -static int ip_rt_bug(struct sk_buff *skb) +static int ip_rt_bug(struct sk_buff **pskb) { + struct sk_buff *skb = *pskb; + printk(KERN_DEBUG "ip_rt_bug: %u.%u.%u.%u -> %u.%u.%u.%u, %s\n", NIPQUAD(skb->nh.iph->saddr), NIPQUAD(skb->nh.iph->daddr), skb->dev ? skb->dev->name : "?"); @@ -1486,6 +1496,7 @@ rth->fl.iif = dev->ifindex; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); + rth->idev = in_dev_get(rth->u.dst.dev); rth->fl.oif = 0; rth->rt_gateway = daddr; rth->rt_spec_dst= spec_dst; @@ -1695,6 +1706,7 @@ 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; @@ -1774,6 +1786,7 @@ rth->fl.iif = dev->ifindex; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); + rth->idev = in_dev_get(rth->u.dst.dev); rth->rt_gateway = daddr; rth->rt_spec_dst= spec_dst; rth->u.dst.input= ip_local_deliver; @@ -2157,6 +2170,7 @@ 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; diff -uNr linux-2.6.7-rc2-mm2/net/ipv6/route.c linux-2.6.7-rc3-mm1/net/ ipv6/route.c --- linux-2.6.7-rc2-mm2/net/ipv6/route.c 2004-06-09 13:15:46.000000000 +0200 +++ linux-2.6.7-rc3-mm1/net/ipv6/route.c 2004-06-09 12:55:19.000000000 +0200 @@ -83,9 +83,11 @@ static struct rt6_info * ip6_rt_copy(struct rt6_info *ort); static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie); static struct dst_entry *ip6_negative_advice(struct dst_entry *); +static void ip6_dst_destroy(struct dst_entry *); static int ip6_dst_gc(void); static int ip6_pkt_discard(struct sk_buff *skb); +static int ip6_pkt_discard_out(struct sk_buff **pskb); static void ip6_link_failure(struct sk_buff *skb); static void ip6_rt_update_pmtu(struct dst_entry *dst, u32 mtu); @@ -95,6 +97,7 @@ .gc = ip6_dst_gc, .gc_thresh = 1024, .check = ip6_dst_check, + .destroy = ip6_dst_destroy, .negative_advice = ip6_negative_advice, .link_failure = ip6_link_failure, .update_pmtu = ip6_rt_update_pmtu, @@ -111,7 +114,7 @@ .error = -ENETUNREACH, .metrics = { [RTAX_HOPLIMIT - 1] = 255, }, .input = ip6_pkt_discard, - .output = ip6_pkt_discard, + .output = ip6_pkt_discard_out, .ops = &ip6_dst_ops, .path = (struct dst_entry*)&ip6_null_entry, } @@ -134,7 +137,15 @@ /* allocate dst with ip6_dst_ops */ static __inline__ struct rt6_info *ip6_dst_alloc(void) { - return dst_alloc(&ip6_dst_ops); + return (struct rt6_info *)dst_alloc(&ip6_dst_ops); +} + +static void ip6_dst_destroy(struct dst_entry *dst) +{ + struct rt6_info *rt = (struct rt6_info *)dst; + if (rt->rt6i_idev != NULL) + in6_dev_put(rt->rt6i_idev); + } /* @@ -566,21 +577,21 @@ struct dst_entry *ndisc_dst_alloc(struct net_device *dev, struct neighbour *neigh, struct in6_addr *addr, - int (*output)(struct sk_buff *)) + int (*output)(struct sk_buff **)) { struct rt6_info *rt = ip6_dst_alloc(); if (unlikely(rt == NULL)) goto out; - if (dev) - dev_hold(dev); + dev_hold(dev); if (neigh) neigh_hold(neigh); else neigh = ndisc_get_neigh(dev, addr); rt->rt6i_dev = dev; + rt->rt6i_idev = in6_dev_get(dev); rt->rt6i_nexthop = neigh; rt->rt6i_expires = 0; rt->rt6i_flags = RTF_LOCAL; @@ -714,6 +725,12 @@ if (rtmsg->rtmsg_src_len) return -EINVAL; #endif + if (rtmsg->rtmsg_ifindex) { + dev = dev_get_by_index(rtmsg->rtmsg_ifindex); + if (!dev) + return -ENODEV; + } + if (rtmsg->rtmsg_metric == 0) rtmsg->rtmsg_metric = IP6_RT_PRIO_USER; @@ -739,13 +756,6 @@ rt->u.dst.output = ip6_output; - if (rtmsg->rtmsg_ifindex) { - dev = dev_get_by_index(rtmsg->rtmsg_ifindex); - err = -ENODEV; - if (dev == NULL) - goto out; - } - ipv6_addr_prefix(&rt->rt6i_dst.addr, &rtmsg->rtmsg_dst, rtmsg->rtmsg_dst_len); rt->rt6i_dst.plen = rtmsg->rtmsg_dst_len; @@ -769,7 +779,7 @@ dev_put(dev); dev = &loopback_dev; dev_hold(dev); - rt->u.dst.output = ip6_pkt_discard; + rt->u.dst.output = ip6_pkt_discard_out; rt->u.dst.input = ip6_pkt_discard; rt->u.dst.error = -ENETUNREACH; rt->rt6i_flags = RTF_REJECT|RTF_NONEXTHOP; @@ -872,6 +882,7 @@ if (!rt->u.dst.metrics[RTAX_ADVMSS-1]) rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.dev = dev; + rt->rt6i_idev = in6_dev_get(dev); return rt6_ins(rt, nlh, _rtattr); out: @@ -1138,6 +1149,9 @@ rt->u.dst.dev = ort->u.dst.dev; if (rt->u.dst.dev) dev_hold(rt->u.dst.dev); + rt->rt6i_idev = ort->rt6i_idev; + if (rt->rt6i_idev) + in6_dev_hold(rt->rt6i_idev); rt->u.dst.lastuse = jiffies; rt->rt6i_expires = 0; @@ -1259,12 +1273,17 @@ int ip6_pkt_discard(struct sk_buff *skb) { - IP6_INC_STATS(Ip6OutNoRoutes); + IP6_INC_STATS(OutNoRoutes); icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_NOROUTE, 0, skb->dev); kfree_skb(skb); return 0; } +int ip6_pkt_discard_out(struct sk_buff **pskb) +{ + return ip6_pkt_discard(*pskb); +} + /* * Add address */ @@ -1282,6 +1301,7 @@ rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; + rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); It seems there is some kind of misreferencing, which was introduced by the previous changes. I'm still trying to figure out what's going on. Reverting these changes allows "cardctl eject" to proceed even when a userspace process has an active open socket. However, reverting these changes breaks IPv6 a little bit for me. I don't have access to BK, but it could be interesting to look at the changesets that caused these changes. Any other ideas? From yasuyuki.kozakai@toshiba.co.jp Wed Jun 9 07:05:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 07:05:31 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59E5Pgi027557 for ; Wed, 9 Jun 2004 07:05:26 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i59E4xpD003243; Wed, 9 Jun 2004 23:04:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i59E4xdD010688; Wed, 9 Jun 2004 23:04:59 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA10686 ; Wed, 9 Jun 2004 23:04:59 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA18023; Wed, 9 Jun 2004 23:04:47 +0900 (JST) Received: by toshiba.co.jp id XAA23742; Wed, 9 Jun 2004 23:04:46 +0900 (JST) Date: Wed, 09 Jun 2004 23:04:44 +0900 (JST) Message-Id: <200406091404.XAA23742@toshiba.co.jp> To: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Cc: usagi-core@linux-ipv6.org Subject: [PATCH]: invalid unregister sysctl table for conntrack From: Yasuyuki Kozakai 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(Wed_Jun__9_23:04:44_2004_590)--" Content-Transfer-Encoding: 7bit X-archive-position: 5803 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: 2161 Lines: 69 ----Next_Part(Wed_Jun__9_23:04:44_2004_590)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, These patches fix the bug that access null pointer when failed to register sysctl table for ip_conntrack. Regards, ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project ----Next_Part(Wed_Jun__9_23:04:44_2004_590)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="conntrack-sysctl-2.4.patch" --- linux-2.4.27-pre5/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-02-18 22:36:32.000000000 +0900 +++ linux-2.4.27-pre5-fixed/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-06-09 23:00:04.454479720 +0900 @@ -377,7 +377,8 @@ ip_ct_sysctl_header = register_sysctl_table(ip_ct_net_table, 0); if (ip_ct_sysctl_header == NULL) { printk("ip_conntrack: can't register to sysctl.\n"); - goto cleanup; + ret = -ENOMEM; + goto cleanup_localinops; } #endif @@ -386,6 +387,7 @@ cleanup: #ifdef CONFIG_SYSCTL unregister_sysctl_table(ip_ct_sysctl_header); + cleanup_localinops: #endif nf_unregister_hook(&ip_conntrack_local_in_ops); cleanup_inoutandlocalops: ----Next_Part(Wed_Jun__9_23:04:44_2004_590)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="conntrack-sysctl-2.6.patch" --- linux-2.6.7-rc3/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-06-09 21:00:34.000000000 +0900 +++ linux-2.6.7-rc3-fixed/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-06-09 22:58:28.765026728 +0900 @@ -540,7 +540,8 @@ ip_ct_sysctl_header = register_sysctl_table(ip_ct_net_table, 0); if (ip_ct_sysctl_header == NULL) { printk("ip_conntrack: can't register to sysctl.\n"); - goto cleanup; + ret = -ENOMEM; + goto cleanup_localinops; } #endif @@ -549,6 +550,7 @@ cleanup: #ifdef CONFIG_SYSCTL unregister_sysctl_table(ip_ct_sysctl_header); + cleanup_localinops: #endif nf_unregister_hook(&ip_conntrack_local_in_ops); cleanup_inoutandlocalops: ----Next_Part(Wed_Jun__9_23:04:44_2004_590)---- From vda@port.imtp.ilyichevsk.odessa.ua Wed Jun 9 07:32:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 07:32:31 -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.12.10/8.12.9) with SMTP id i59EWMgi028760 for ; Wed, 9 Jun 2004 07:32:26 -0700 Received: (qmail 23446 invoked by alias); 9 Jun 2004 12:45:28 -0000 Received: from vda@port.imtp.ilyichevsk.odessa.ua by guard by uid 80 with qmail-scanner-1.22 ( Clear:RC:1(172.16.42.177):. Processed in 0.364045 secs); 09 Jun 2004 12:45:28 -0000 Received: from unknown (HELO firebird) (172.16.42.177) by 0 (172.16.22.3) with ESMTP; 09 Jun 2004 12:45:24 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Denis Vlasenko To: Julian Anastasov Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address Date: Wed, 9 Jun 2004 15:45:23 +0300 X-Mailer: KMail [version 1.4] Cc: netdev@oss.sgi.com, , , , , , References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200406091545.23674.vda@port.imtp.ilyichevsk.odessa.ua> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i59EWMgi028760 X-archive-position: 5804 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: 1003 Lines: 30 On Wednesday 09 June 2004 15:18, Julian Anastasov wrote: > Hello, > > On Wed, 9 Jun 2004, Denis Vlasenko wrote: > > I observe that UDP sockets listening on ANY > > send response packets with ip addr derived from > > ip address of interface which is used to send 'em > > instead of using dst ip address of client's packet. > > > > I was bitten by this with DNS and NTP. > > The problem is in the apps. You have some options: > > - use sockets listening on ANY and using sendmsg with IP_PKTINFO > and providing the desired src IP in ipi_spec_dst > > - you can also create many listener sockets listening on > particular src IP and to reply using the socket where the > request is received, because the kernel does not know any > association between request and reply packets if the listener > is bound to ANY. Aha! That's why ntpd is so eager to bind to everything imaginable! (Which does not help BTW with non-permanent interfaces like ppp, tun etc). /me googling for that IP_PKTINFO thing... -- vda From felipe_alfaro@linuxmail.org Wed Jun 9 08:18:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 08:18:20 -0700 (PDT) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59FI0gi030373 for ; Wed, 9 Jun 2004 08:18:01 -0700 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 0D94242E3D; Wed, 9 Jun 2004 17:17:53 +0200 (CEST) Subject: Re: 2.6.7-rc3: waiting for eth0 to become free From: Felipe Alfaro Solana To: Stephen Hemminger Cc: NetDev Mailinglist , Kernel Mailinglist In-Reply-To: <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> Content-Type: multipart/mixed; boundary="=-u2PIj7ufbPZjZ2ZX0Uxe" Date: Wed, 09 Jun 2004 17:18:02 +0200 Message-Id: <1086794282.1706.2.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 (1.5.9.1-2) X-archive-position: 5805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: netdev Content-Length: 5173 Lines: 149 --=-u2PIj7ufbPZjZ2ZX0Uxe Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2004-06-08 at 14:02 -0700, Stephen Hemminger wrote: > On Tue, 08 Jun 2004 22:09:29 +0200 > Felipe Alfaro Solana wrote: > > > On Tue, 2004-06-08 at 12:42 -0700, Stephen Hemminger wrote: > > > On Tue, 08 Jun 2004 21:18:30 +0200 > > > Felipe Alfaro Solana wrote: > > > > > > > Hi! > > > > > > > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > > > > "cardctl eject" so the system won't freeze when resuming. "cardctl > > > > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > > > > network sockets opened (for example, Evolution mantaining a connection > > > > against an IMAP server): the card is ejected (well, not physically), > > > > even when there are ESTABLISHED connections. > > > > > > > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > > > > holds any socket open. After a while the "unregister_netdevice: waiting > > > > for eth0 to become free" message starts appearing on the kernel message > > > > ring. The only apparent solution is killing that program, ejecting the > > > > card from its slot and wait until 3c59x.o usage count reaches zero. > > > > > > > > Can someone tell me what's going on here? > > > > Thank you very much. > > > > > > What protocols are you running? Is IPV6 loaded? > > > > I'm using IPv4, IPv6 and IPSec ESP with AES/CBC. > > Do you want .config? > > Not really, could you see if it is an IPv6 vs IPSec problem by not running/loading > one or the other. > > What is happening is that some subsystem is holding a reference to the device (calling dev_hold()) > but not cleaning up (calling dev_put). It can be a hard to track which of the many > things routing, etc are not being cleared properly. Look for routes that still > get stuck (ip route) and neighbor cache entries. Most of these end up being > protocol bugs. The two attached patches, one for net/ipv4/route.c, the other for net/ ipv6/route.c fix all my problems when running "cardctl eject" while a program mantains an open network socket (ESTABLISHED). Both patches apply cleanly against 2.6.7-rc3 and 2.6.7-rc3-mm1. I'm not completely sure what has changed in 2.6.7-rc3 that is breaking cardctl for me, as it Just Worked(TM) fine in 2.6.7-rc2. Hope this can throw some light at this issue. Thanks! --=-u2PIj7ufbPZjZ2ZX0Uxe Content-Disposition: attachment; filename=IPV4.patch Content-Type: text/x-patch; name=IPV4.patch; charset=utf-8 Content-Transfer-Encoding: 7bit --- linux/net/ipv4/route.c 2004-06-09 16:10:40.612487739 +0200 +++ linux/net/ipv4/route.c 2004-06-09 16:47:34.927939813 +0200 @@ -1040,8 +1040,6 @@ rt->u.dst.child = NULL; if (rt->u.dst.dev) dev_hold(rt->u.dst.dev); - if (rt->idev) - in_dev_hold(rt->idev); rt->u.dst.obsolete = 0; rt->u.dst.lastuse = jiffies; rt->u.dst.path = &rt->u.dst; @@ -1496,7 +1494,6 @@ rth->fl.iif = dev->ifindex; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); rth->fl.oif = 0; rth->rt_gateway = daddr; rth->rt_spec_dst= spec_dst; @@ -1706,7 +1703,6 @@ 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; @@ -1786,7 +1782,6 @@ rth->fl.iif = dev->ifindex; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); rth->rt_gateway = daddr; rth->rt_spec_dst= spec_dst; rth->u.dst.input= ip_local_deliver; @@ -2170,7 +2165,6 @@ 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; --=-u2PIj7ufbPZjZ2ZX0Uxe Content-Disposition: attachment; filename=IPV6.patch Content-Type: text/x-patch; name=IPV6.patch; charset=utf-8 Content-Transfer-Encoding: 7bit --- linux/net/ipv6/route.c 2004-06-09 15:10:03.000000000 +0200 +++ linux/net/ipv6/route.c 2004-06-09 16:52:51.219867318 +0200 @@ -584,14 +584,14 @@ if (unlikely(rt == NULL)) goto out; - dev_hold(dev); + if(dev) + dev_hold(dev); if (neigh) neigh_hold(neigh); else neigh = ndisc_get_neigh(dev, addr); rt->rt6i_dev = dev; - rt->rt6i_idev = in6_dev_get(dev); rt->rt6i_nexthop = neigh; rt->rt6i_expires = 0; rt->rt6i_flags = RTF_LOCAL; @@ -882,7 +882,6 @@ if (!rt->u.dst.metrics[RTAX_ADVMSS-1]) rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.dev = dev; - rt->rt6i_idev = in6_dev_get(dev); return rt6_ins(rt, nlh, _rtattr); out: @@ -1301,7 +1300,6 @@ rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; - rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); --=-u2PIj7ufbPZjZ2ZX0Uxe-- From jt@bougret.hpl.hp.com Wed Jun 9 11:17:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 11:17:18 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59IGvgi008101 for ; Wed, 9 Jun 2004 11:16:58 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 550811C113BE; Wed, 9 Jun 2004 10:40:22 -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 KAA03158; Wed, 9 Jun 2004 10:41:34 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BY73l-00071X-00; Wed, 09 Jun 2004 10:40:21 -0700 Date: Wed, 9 Jun 2004 10:40:21 -0700 To: jamal Cc: netdev@oss.sgi.com Subject: Re: in-driver QoS Message-ID: <20040609174021.GA26159@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040608184831.GA18462@bougret.hpl.hp.com> <1086722317.1023.18.camel@jzny.localdomain> <20040608195238.GA21089@bougret.hpl.hp.com> <1086728139.1023.71.camel@jzny.localdomain> <20040608220109.GA24536@bougret.hpl.hp.com> <1086752809.1049.62.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086752809.1049.62.camel@jzny.localdomain> 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: 5806 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: 3421 Lines: 81 On Tue, Jun 08, 2004 at 11:46:49PM -0400, jamal wrote: > On Tue, 2004-06-08 at 18:01, Jean Tourrilhes wrote: > > > Yep. This impact the contention process. > > This is similar to what was implemented in 100VG / IEEE > > 802.12, but in more elaborated. > > so the only differentiation is on backoff and contention window > parameters. In other words, higher prio will get opportunity to be more > of a hog or aggressive? Yep. It's like a fast pass to cut the line at DisneyWorld. > > There is 4 FIFOs (or whichever number then want to configure) > > in parallel. > > Most likely, the FIFOs will share the same memory pool on the > > card, so when a FIFO is full, most likely the other FIFOs will be full > > or close to it. > > How do you reach such a conclusion? > There maybe packets of the same priority for longs periods of time. If all the FIFO take from the same memory pool, when one FIFO is full, it means that the memory pool is exhausted. If the memory pool is exhausted, then you can't fill the other FIFOs. > But then you loose sync with the qdisc level scheduling. > Assume a burst of low prio packets arrive, they get drained to the low > prio FIFO in the driver. It gets full and now we lock the driver. > Next a burst of high prio packets come in and they cantt be sent to the > driver until all low prio packets already on FIFO are sent. Yep. That's no worse than what we have today with a single FIFO in today's cards. Remember that amount of buffer on the card is limited, so we are not talking of an incredible number of packets in those FIFO. I'm 100% with Andy in suggesting to keep hardware FIFO as short as possible, precisely so that the TC scheduling is effective. If you let the card scheduler take over, it will screw up your TC scheduling no matter what, unless the card scheduler use the exact same scheduling as TC (which is unlikely for complex TC policies). If the card policy is to always drain the highest priority queue first, and you want to guarantee a minimum bandwidth for low priority traffic at the TC level, if you let the card scheduler do its business and always feed high priority traffic when it wants it, then there is no way you can guarantee your minimum bandwidth for low priority traffic. > > But, we are talking there as if the hardware was going to have > > some incredibly smart scheduler across FIFOs. From my experience with > > wireless MAC implementations, the behaviour will be really simplistic > > (always send from the highest priority FIFO), if not totally > > broken. > > "Always send from highest priority" is fine. No, it's fine only if TC policy is "Always send from highest priority". If TC policy is different, then it's not fine at all. > Its what the default linux > scheduler and the prio qdisc do. A lot of research and experienece has > gone into understanding their behaviors. > Perhaps you could tell users to configure such prioritization when using > these NICs. You assume that the card scheduler will be configurable, and work as expected. Wait and see ;-) > We need to make chnages and do it properly. > Your approach to use only one priority/FIFO is not sane. > Of course the wireless people dont have to use it - Although that will > be a mistake. I have a NIC that has two DMA channels which i plan to map > to X priority levels at the the qdisc levels. Good luck ;-) > cheers, > jamal Have fun... Jean From ahu@outpost.ds9a.nl Wed Jun 9 11:21:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 11:21:38 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59ILNgi008467 for ; Wed, 9 Jun 2004 11:21:24 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 39727444F; Wed, 9 Jun 2004 19:52:43 +0200 (CEST) Date: Wed, 9 Jun 2004 19:52:43 +0200 From: bert hubert To: davem@redhat.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [DOCUMENTATION PATCH] Missing net sysctls, some fixed, rest flagged Message-ID: <20040609175242.GA13875@outpost.ds9a.nl> Mail-Followup-To: bert hubert , davem@redhat.com, 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.3.28i X-archive-position: 5807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 3525 Lines: 121 Dave, Lists, I ran the following (crappy) script: for b in $(for a in $(find | grep -v eth0 | grep -v binfmt) do basename $a done | sort -u); do if rgrep -q $b ~/download/linux-2.6.6/Documentation/ then touch /tmp/script else echo $b missing fi done In /proc/sys/ and found a host of undocumented sysctls. This patch documents a number of them, and at least mentions the rest as 'TODO'. Please verify my code-inspired documentation before applying! --- linux-2.6.6/Documentation/networking/ip-sysctl.txt.ahu 2004-06-09 18:53:29.000000000 +0200 +++ linux-2.6.6/Documentation/networking/ip-sysctl.txt 2004-06-09 19:46:15.000000000 +0200 @@ -17,6 +17,16 @@ Disable Path MTU Discovery. default FALSE +min_pmtu - INTEGER + default 562 - minimum discovered Path MTU + +mtu_expires - INTEGER + FIXME: unknown + +min_adv_mss - INTEGER + The advertised MSS depends on the first hop route MTU, but will + never be lower than this setting + IP Fragmentation: ipfrag_high_thresh - INTEGER @@ -340,6 +350,17 @@ more rapidly. Default: 1 + +tcp_frto - BOOLEAN + Enables F-RTO, an enhanced recovery algorithm for TCP retransmission + timeouts + +somaxconn - INTEGER + Limit of TCP listen backlog, known in userspace as SOMAXCONN. + Defaults to 128 + +IP Variables: + ip_local_port_range - 2 INTEGERS Defines the local port range that is used by TCP and UDP to choose the local port. The first number is the first, the @@ -581,6 +602,19 @@ The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface} +app_solicit - INTEGER + The maximum number of probes to send to the user space ARP daemon + via netlink before dropping back to multicast probes (see + mcast_solicit). Defaults to 0. + +disable_policy - BOOLEAN + Disable IPSEC policy (SPD) for this interface + +disable_xfrm - BOOLEAN + Disable IPSEC encryption on this interface, whatever the policy + + + tag - INTEGER Allows you to write a number, which can be used as required. Default value is 0. @@ -799,4 +833,25 @@ Default: 1 +UNDOCUMENTED: + +dev_weight FIXME +discovery_slots FIXME +discovery_timeout FIXME +fast_poll_increase FIXME +ip6_queue_maxlen FIXME +lap_keepalive_time FIXME +lo_cong FIXME +max_baud_rate FIXME +max_dgram_qlen FIXME +max_noreply_time FIXME +max_tx_data_size FIXME +max_tx_window FIXME +min_tx_turn_time FIXME +mod_cong FIXME +no_cong FIXME +no_cong_thresh FIXME +slot_timeout FIXME +warn_noreply_time FIXME + $Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $ --- linux-2.6.6/Documentation/filesystems/proc.txt.ahu 2004-06-09 19:31:17.000000000 +0200 +++ linux-2.6.6/Documentation/filesystems/proc.txt 2004-06-09 19:32:09.000000000 +0200 @@ -1628,7 +1628,8 @@ Writing to this file results in a flush of the routing cache. -gc_elastic, gc_interval, gc_min_interval, gc_tresh, gc_timeout +gc_elasticity, gc_interval, gc_min_interval, gc_tresh, gc_timeout, +gc_thresh, gc_thresh1, gc_thresh2, gc_thresh3 -------------------------------------------------------------- Values to control the frequency and behavior of the garbage collection -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From vkondra@mail.ru Wed Jun 9 11:27:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 11:27:36 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59IRXgi009295 for ; Wed, 9 Jun 2004 11:27:34 -0700 Received: from [81.218.179.11] (port=17487 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BY7nP-00059o-00; Wed, 09 Jun 2004 22:27:32 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: in-driver QoS Date: Wed, 9 Jun 2004 21:27:28 +0300 User-Agent: KMail/1.6.2 Cc: jt@hpl.hp.com References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406090851.40691.vkondra@mail.ru> <1086780010.1051.106.camel@jzny.localdomain> In-Reply-To: <1086780010.1051.106.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406092127.28477.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5808 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: 1777 Lines: 39 > > Due to single queue, I can't provide separate back > > pressure for different access categories. What I do now, I do some > > internal buffering and netif_stop_queue() when total number of packets > > (or bytes) exceed some threshold. Of course, with watermarks to fight > > jitter. > > Will work fine if you have mostly only one priority really. Unfortunately, yes. > > > Let's consider real example. Some application do FTP transfer, lots of > > data. Simultaneously, voice-over-IP connection invoked. Now question is: > > how to assure voice quality? > > Non-trivial with current setup. > > > Accordingly to TGe, voice is send either with high > > priority, or in TSPEC. If we will send all packets with high priority, we > > will hit ourselves. If we can't provide some back pressure for low > > priority traffic, it will block voice packets, since some moment you > > should netif_stop_queue(). > > > > Ideal would be if I can call netif_stop_queue(id), separately for each > > id. > > Indeed. > Looking at the transmit path code it seems doable. > for each dev->id you also maintain a dev->id_state. > We either use skb->fwmark or skb->priority to map to the different BTW, what is fwmark? in 2.6.6 it is not present. > dev->ids. > The major challenge would be how to start the different queues once they > are stopped. I suspect there is only tx completed interupt; i take it > you can tell when each of the FIFOs is ready to swallow more packets? Sure. I know when each DMA queue have space to accept new packets. w.r.t Tx discipline, it is really like 4 (taking into account TSPEC, see my mail about TGe, minimum 5 for STA and 6 (i did not said about power save buffering) for AP) independent devices. I see you got the idea. Question is, how to implement it. From vincent-perrier@club-internet.fr Wed Jun 9 12:53:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 12:53:45 -0700 (PDT) Received: from relay-6v.club-internet.fr (relay-6v.club-internet.fr [194.158.96.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59Jrggi015457 for ; Wed, 9 Jun 2004 12:53:43 -0700 Received: from club-internet.fr (l09m-17-193.d2.club-internet.fr [212.194.104.193]) by relay-6v.club-internet.fr (Postfix) with ESMTP id 9DAD0256C8 for ; Wed, 9 Jun 2004 21:53:41 +0200 (CEST) Message-ID: <40C76ACF.6010104@club-internet.fr> Date: Wed, 09 Jun 2004 21:53:51 +0200 From: Vincent Perrier User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.6) Gecko/20040122 X-Accept-Language: fr, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Free software to help test qdiscs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vincent-perrier@club-internet.fr Precedence: bulk X-list: netdev Content-Length: 187 Lines: 4 I have a free software tool for htb users that can be usefull at http://www.rawsoft.org/ It gives a real time monitoring of htb (or cbq or hfsc) behaviour on tcl-tk plots, try it. From shemminger@osdl.org Wed Jun 9 13:36:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 13:36:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59Ka0gi016741 for ; Wed, 9 Jun 2004 13:36:00 -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 i59KWQr32392; Wed, 9 Jun 2004 13:32:27 -0700 Date: Wed, 9 Jun 2004 13:32:26 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: "Venkatesan, Ganesh" , cramerj , "Ronciak, John" , netdev@oss.sgi.com Subject: [PATCH] e1000 module parameters use new format Message-Id: <20040609133226.7862e2dd@dell_ss3.pdx.osdl.net> In-Reply-To: <40C607D9.5090506@pobox.com> References: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> <20040608110420.3b93338d@dell_ss3.pdx.osdl.net> <40C607D9.5090506@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: 5810 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: 947 Lines: 26 The e1000 driver was mixing old/new module parameter methods. Okay, here is the other way to fix it by making the other module parameters the new format.. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/e1000/e1000_param.c b/drivers/net/e1000/e1000_param.c --- a/drivers/net/e1000/e1000_param.c 2004-06-09 13:31:00 -07:00 +++ b/drivers/net/e1000/e1000_param.c 2004-06-09 13:31:00 -07:00 @@ -55,10 +55,11 @@ * 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(name, desc) \ +static int __devinitdata name[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ +static int num_##name = 0; \ +module_param_array(name, int, num_##name, 0); \ +MODULE_PARM_DESC(name, desc); /* Transmit Descriptor Count * From davem@redhat.com Wed Jun 9 13:42:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 13:42:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59Kgdgi017131 for ; Wed, 9 Jun 2004 13:42:41 -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 i59Kgai5013826; Wed, 9 Jun 2004 16:42: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 i59Kga011592; Wed, 9 Jun 2004 16:42: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 i59KgM3H013181; Wed, 9 Jun 2004 16:42:23 -0400 Date: Wed, 9 Jun 2004 13:38:50 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [IPV6] IP6CB Message-Id: <20040609133850.2d1a7cd0.davem@redhat.com> In-Reply-To: <20040608.120817.49979734.yoshfuji@linux-ipv6.org> References: <20040608.120817.49979734.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 i59Kgdgi017131 X-archive-position: 5811 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: 188 Lines: 7 On Tue, 08 Jun 2004 12:08:17 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Introduce IP6CB(skb), like other protocols such as IPv4. Applied, thanks. From davidsen@tmr.com Wed Jun 9 14:11:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 14:11:19 -0700 (PDT) Received: from oddball.prodigy.com (prgy-npn1.prodigy.com [207.115.54.37]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59LB8gi017847 for ; Wed, 9 Jun 2004 14:11:08 -0700 Received: from tmr.com (oddball.prodigy.com [127.0.0.1]) by oddball.prodigy.com (8.11.6/8.11.6) with ESMTP id i59L94n07261; Wed, 9 Jun 2004 17:09:07 -0400 Message-ID: <40C77C70.5070409@tmr.com> Date: Wed, 09 Jun 2004 17:09:04 -0400 From: Bill Davidsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> In-Reply-To: <20040608210809.GA10542@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev Content-Length: 1619 Lines: 46 Roger Luethi wrote: > On Mon, 07 Jun 2004 14:57:23 -0700, David S. Miller wrote: > >>On Mon, 7 Jun 2004 23:28:04 +0200 >>Roger Luethi wrote: >> >> >>>What is the correct response if a user passes ethtool speed or duplex >>>arguments while autoneg is on? Some possible answers are: >>> > > [...] > >>speed and duplex fields should be silently ignored in this case > > > It may not matter much because few people care about forced media these > days. And it is debatable whether trying to guess the users intention > is a good idea (we lack means for users to manipulate autoneg results > via advertisted values but that's no big deal). It does sometimes matter, because even these days we sometimes see a case where a brand name switch (like Cisco) and a brand name card (Intel, 3COM) negotiate but just don't "work right" later. In those cases forcing on both ends or just the NIC end results in a fully functional connection. We usually do this with module parameters, but do use ethtool (or mii-tool) on occasion. > > However, "silently ignoring" strikes me as a very poor choice, in > stark contrast to Unix/Linux tradition. A user issues a command which > cannot be executed and gets the same response that is used to indicate > success!? What school of user interface design is that? How is that > not confusing users? Yah. Seeing this happen while autonegotiation is in progress is a small and unlikely window of course! -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From shemminger@osdl.org Wed Jun 9 14:41:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 14:41:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59LfTgi018672 for ; Wed, 9 Jun 2004 14:41:30 -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 i59LfKr14127; Wed, 9 Jun 2004 14:41:20 -0700 Date: Wed, 9 Jun 2004 14:41:20 -0700 From: Stephen Hemminger To: Jeb Cramer , John Ronciak , Ganesh Venkatesan Cc: netdev@oss.sgi.com Subject: [PATCH] e1000 - get rid of tx_lock Message-Id: <20040609144120.1655eee0@dell_ss3.pdx.osdl.net> In-Reply-To: <20040608102729.620dd1fc@dell_ss3.pdx.osdl.net> References: <20040608102729.620dd1fc@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: 5813 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: 2262 Lines: 71 The e1000 driver has an tx_lock which unneeded. It is only used to protect the start/stop queue flags which are already handled by doing atomic bit operations. Also netif_wake_queue uses test_and_clear_bit so testing for stopped before calling it is unnecessary. Surprisingly, without this change the additional overhead causes my system to transmit timeout and never recover when using NAPI. With the tx_lock removed, the ring doesn't fill and lockup. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h --- a/drivers/net/e1000/e1000.h 2004-06-09 14:35:23 -07:00 +++ b/drivers/net/e1000/e1000.h 2004-06-09 14:35:23 -07:00 @@ -208,7 +208,6 @@ /* TX */ struct e1000_desc_ring tx_ring; - spinlock_t tx_lock; uint32_t txd_cmd; uint32_t tx_int_delay; uint32_t tx_abs_int_delay; diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2004-06-09 14:35:23 -07:00 +++ b/drivers/net/e1000/e1000_main.c 2004-06-09 14:35:23 -07:00 @@ -691,7 +691,6 @@ atomic_set(&adapter->irq_sem, 1); spin_lock_init(&adapter->stats_lock); - spin_lock_init(&adapter->tx_lock); return 0; } @@ -1733,7 +1732,6 @@ 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 long flags; unsigned int len = skb->len; int count = 0; unsigned int mss = 0; @@ -1777,15 +1775,12 @@ if(adapter->pcix_82544) count += nr_frags; - spin_lock_irqsave(&adapter->tx_lock, flags); /* 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; } - spin_unlock_irqrestore(&adapter->tx_lock, flags); if(adapter->hw.mac_type == e1000_82547) { if(e1000_82547_fifo_workaround(adapter, skb)) { @@ -2208,12 +2203,8 @@ tx_ring->next_to_clean = i; - spin_lock(&adapter->tx_lock); - - if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev)) + if(cleaned) netif_wake_queue(netdev); - - spin_unlock(&adapter->tx_lock); return cleaned; } From davem@redhat.com Wed Jun 9 15:16:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 15:16:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59MGdgi019670 for ; Wed, 9 Jun 2004 15:16:40 -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 i59MGXi5005302; Wed, 9 Jun 2004 18:16:33 -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 i59MGX009308; Wed, 9 Jun 2004 18:16:33 -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 i59MGKYe021953; Wed, 9 Jun 2004 18:16:20 -0400 Date: Wed, 9 Jun 2004 15:12:46 -0700 From: "David S. Miller" To: Roger Luethi Cc: davidsen@tmr.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics Message-Id: <20040609151246.1c28c4d9.davem@redhat.com> In-Reply-To: <20040609213850.GA17243@k3.hellgate.ch> References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> <40C77C70.5070409@tmr.com> <20040609213850.GA17243@k3.hellgate.ch> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5814 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: 298 Lines: 9 On Wed, 9 Jun 2004 23:38:50 +0200 Roger Luethi wrote: > I just killed the module parameters in my via-rhine development > tree. That is absolutely the correct thing to do, module parameters for link settings are %100 deprecated, people need to use ethtool for everything. From evil@g-house.de Wed Jun 9 15:48:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 15:48:56 -0700 (PDT) Received: from mail.g-house.de (ns1.g-housing.de [62.75.136.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59Mmpgi021137 for ; Wed, 9 Jun 2004 15:48:51 -0700 Received: from g0b46.g.pppool.de ([80.185.11.70] helo=sheep.housecafe.de) by mail.g-house.de with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1BYBu8-00016b-OK; Thu, 10 Jun 2004 00:50:45 +0200 Received: from prinz.housecafe.de ([192.168.1.11]) by sheep.housecafe.de with esmtp (Exim 4.34) id 1BYBsD-0001cq-AS; Thu, 10 Jun 2004 00:48:45 +0200 Message-ID: <40C793CE.6000609@g-house.de> Date: Thu, 10 Jun 2004 00:48:46 +0200 From: Christian Kujau User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felipe Alfaro Solana CC: NetDev Mailinglist , Kernel Mailinglist Subject: Re: 2.6.7-rc3: waiting for eth0 to become free References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> <1086794282.1706.2.camel@teapot.felipe-alfaro.com> In-Reply-To: <1086794282.1706.2.camel@teapot.felipe-alfaro.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: evil@g-house.de Precedence: bulk X-list: netdev Content-Length: 1519 Lines: 44 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felipe Alfaro Solana wrote: |>What is happening is that some subsystem is holding a reference to the device (calling dev_hold()) |>but not cleaning up (calling dev_put). It can be a hard to track which of the many |>things routing, etc are not being cleared properly. Look for routes that still |>get stuck (ip route) and neighbor cache entries. Most of these end up being |>protocol bugs. | | | The two attached patches, one for net/ipv4/route.c, the other for net/ | ipv6/route.c fix all my problems when running "cardctl eject" while a | program mantains an open network socket (ESTABLISHED). | | Both patches apply cleanly against 2.6.7-rc3 and 2.6.7-rc3-mm1. | I'm not completely sure what has changed in 2.6.7-rc3 that is breaking | cardctl for me, as it Just Worked(TM) fine in 2.6.7-rc2. do you know, by any chance, if this error is dependent to eth0 only or could help for my error message too: unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 happened just a few hours ago (2.6.7-rc3), i had to reboot the box anyway, but pppd was not able to die (even with kill -9) Christian. - -- BOFH excuse #258: That's easy to fix, but I can't be bothered. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAx5PN+A7rjkF8z0wRAuR+AJ41024qDMPVWYlVeofUZ6N50E3oRwCfeqhs /GxxIqmDbClJXw/i2WNhJt4= =lHgP -----END PGP SIGNATURE----- From romieu@fr.zoreil.com Wed Jun 9 15:50:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 15:50:39 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59MoXgi021717 for ; Wed, 9 Jun 2004 15:50:34 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i59MoMon011131; Thu, 10 Jun 2004 00:50:22 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i59MoLv9011130; Thu, 10 Jun 2004 00:50:21 +0200 Date: Thu, 10 Jun 2004 00:50:21 +0200 From: Francois Romieu To: Stephen Hemminger Cc: Jeb Cramer , John Ronciak , Ganesh Venkatesan , netdev@oss.sgi.com Subject: Re: [PATCH] e1000 - get rid of tx_lock Message-ID: <20040610005021.A10503@electric-eye.fr.zoreil.com> References: <20040608102729.620dd1fc@dell_ss3.pdx.osdl.net> <20040609144120.1655eee0@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040609144120.1655eee0@dell_ss3.pdx.osdl.net>; from shemminger@osdl.org on Wed, Jun 09, 2004 at 02:41:20PM -0700 X-Organisation: Land of Sunshine Inc. X-archive-position: 5816 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: 903 Lines: 29 Stephen Hemminger : > The e1000 driver has an tx_lock which unneeded. It is only used to protect > the start/stop queue flags which are already handled by doing atomic bit > operations. I am not terribly used to this code but as far as I can read it, the lock avoids that the condition which leads to netif_stop_queue() in the xmit thread changes (due to an irq) "just before" netif_stop_queue() is actually called. So, if the lock is removed, I would be tempted to have the xmit thread issue an smp_rmb() and revalidate that it was fine to netif_stop_queue(). Otherwise, one could have: [e1000_xmit_frame] if (E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2 ) { <- at the same time on a different CPU -> [...] e1000_clean_tx_irq::netif_wake_queue() // Plenty of room has been made [...] <- back to e1000_xmit_frame() -> netif_stop_queue return 1; } -- Ueimor From mashirle@us.ibm.com Wed Jun 9 16:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 16:01:18 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59N19gi022820 for ; Wed, 9 Jun 2004 16:01:16 -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.2) with ESMTP id i59N0uxp530416; Wed, 9 Jun 2004 19:00:56 -0400 Received: from IBM-KHXOIC5VFKN.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 i59N0tTm185142; Wed, 9 Jun 2004 17:00:55 -0600 From: Shirley Ma To: davem@redhat.com Subject: [PATCH] dst allocation problem in ndisc Date: Wed, 9 Jun 2004 16:00:29 -0700 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, xma@us.ibm.com References: <200403311326.43647.mashirle@us.ibm.com> <200405261308.54281.mashirle@us.ibm.com> In-Reply-To: <200405261308.54281.mashirle@us.ibm.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Oa5xAH0hW4Xu7qQ" Message-Id: <200406091600.30568.mashirle@us.ibm.com> X-archive-position: 5817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5277 Lines: 197 --Boundary-00=_Oa5xAH0hW4Xu7qQ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline When creating dst entry from ndisc, the dst entry of pmtu is not set, and the outout for this kind of dst entry is set to ip_output2 instead of ip_output. This could lead to send bigger packets through these des entries without fragmentation, and uninitialized pmtu could lead the network unreachable. These problems are easy reproduced when configuring IPSEC for ipv6. IPSEC could pick up dst entry created by ndisc as child des entry if ndisc dst entry generated earlier. If sending bigger packets through IPSEC, the ip output2 will send bigger packets out, the driver will drop these packets on receiver side. Also the dst_entry pmtu will be 0, the network is unreachable. The patch has been tested against 2.6.6. I am not sure why ndisc genereats dst entry with output equal to ip6_output2 not ip6_output. If ndisc sends bigger packets, it will break also. Here is the patch against 2.6.6 kernel. Please review this patch. -- Thanks Shirley Ma IBM Linux Technology Center --Boundary-00=_Oa5xAH0hW4Xu7qQ Content-Type: text/x-diff; charset="iso-2022-jp"; name="linux-2.6.6-dst.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.6-dst.patch" diff -urN linux-2.6.6/net/ipv6/ndisc.c linux-2.6.6-dst/net/ipv6/ndisc.c --- linux-2.6.6/net/ipv6/ndisc.c 2004-05-09 19:32:39.000000000 -0700 +++ linux-2.6.6-dst/net/ipv6/ndisc.c 2004-06-09 15:35:37.000000000 -0700 @@ -395,7 +395,7 @@ ndisc_flow_init(&fl, NDISC_NEIGHBOUR_ADVERTISEMENT, src_addr, daddr); - dst = ndisc_dst_alloc(dev, neigh, daddr, ip6_output2); + dst = ndisc_dst_alloc(dev, neigh, daddr, ip6_output); if (!dst) return; @@ -486,7 +486,7 @@ ndisc_flow_init(&fl, NDISC_NEIGHBOUR_SOLICITATION, saddr, daddr); - dst = ndisc_dst_alloc(dev, neigh, daddr, ip6_output2); + dst = ndisc_dst_alloc(dev, neigh, daddr, ip6_output); if (!dst) return; @@ -562,7 +562,7 @@ ndisc_flow_init(&fl, NDISC_ROUTER_SOLICITATION, saddr, daddr); - dst = ndisc_dst_alloc(dev, NULL, daddr, ip6_output2); + dst = ndisc_dst_alloc(dev, NULL, daddr, ip6_output); if (!dst) return; diff -urN linux-2.6.6/net/ipv6/route.c linux-2.6.6-dst/net/ipv6/route.c --- linux-2.6.6/net/ipv6/route.c 2004-05-09 19:33:05.000000000 -0700 +++ linux-2.6.6-dst/net/ipv6/route.c 2004-06-09 15:41:49.000000000 -0700 @@ -558,6 +558,56 @@ } } +/* Clean host part of a prefix. Not necessary in radix tree, + but results in cleaner routing tables. + + Remove it only when all the things will work! + */ + +static int ipv6_get_mtu(struct net_device *dev) +{ + int mtu = IPV6_MIN_MTU; + struct inet6_dev *idev; + + idev = in6_dev_get(dev); + if (idev) { + mtu = idev->cnf.mtu6; + in6_dev_put(idev); + } + return mtu; +} + +static inline unsigned int ipv6_advmss(unsigned int mtu) +{ + mtu -= sizeof(struct ipv6hdr) + sizeof(struct tcphdr); + + if (mtu < ip6_rt_min_advmss) + mtu = ip6_rt_min_advmss; + + /* + * Maximal non-jumbo IPv6 payload is IPV6_MAXPLEN and + * corresponding MSS is IPV6_MAXPLEN - tcp_header_size. + * IPV6_MAXPLEN is also valid and means: "any MSS, + * rely only on pmtu discovery" + */ + if (mtu > IPV6_MAXPLEN - sizeof(struct tcphdr)) + mtu = IPV6_MAXPLEN; + return mtu; +} + +static int ipv6_get_hoplimit(struct net_device *dev) +{ + int hoplimit = ipv6_devconf.hop_limit; + struct inet6_dev *idev; + + idev = in6_dev_get(dev); + if (idev) { + hoplimit = idev->cnf.hop_limit; + in6_dev_put(idev); + } + return hoplimit; +} + /* Protected by rt6_lock. */ static struct dst_entry *ndisc_dst_gc_list; @@ -585,6 +635,8 @@ rt->rt6i_metric = 0; atomic_set(&rt->u.dst.__refcnt, 1); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = 255; + rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); + rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.output = output; write_lock_bh(&rt6_lock); @@ -641,56 +693,6 @@ return (atomic_read(&ip6_dst_ops.entries) > ip6_rt_max_size); } -/* Clean host part of a prefix. Not necessary in radix tree, - but results in cleaner routing tables. - - Remove it only when all the things will work! - */ - -static int ipv6_get_mtu(struct net_device *dev) -{ - int mtu = IPV6_MIN_MTU; - struct inet6_dev *idev; - - idev = in6_dev_get(dev); - if (idev) { - mtu = idev->cnf.mtu6; - in6_dev_put(idev); - } - return mtu; -} - -static inline unsigned int ipv6_advmss(unsigned int mtu) -{ - mtu -= sizeof(struct ipv6hdr) + sizeof(struct tcphdr); - - if (mtu < ip6_rt_min_advmss) - mtu = ip6_rt_min_advmss; - - /* - * Maximal non-jumbo IPv6 payload is IPV6_MAXPLEN and - * corresponding MSS is IPV6_MAXPLEN - tcp_header_size. - * IPV6_MAXPLEN is also valid and means: "any MSS, - * rely only on pmtu discovery" - */ - if (mtu > IPV6_MAXPLEN - sizeof(struct tcphdr)) - mtu = IPV6_MAXPLEN; - return mtu; -} - -static int ipv6_get_hoplimit(struct net_device *dev) -{ - int hoplimit = ipv6_devconf.hop_limit; - struct inet6_dev *idev; - - idev = in6_dev_get(dev); - if (idev) { - hoplimit = idev->cnf.hop_limit; - in6_dev_put(idev); - } - return hoplimit; -} - /* * */ --Boundary-00=_Oa5xAH0hW4Xu7qQ-- From mashirle@us.ibm.com Wed Jun 9 16:30:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 16:30:07 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i59NTvgi027028 for ; Wed, 9 Jun 2004 16:30:04 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i59NTjQ1142534; Wed, 9 Jun 2004 19:29:45 -0400 Received: from IBM-KHXOIC5VFKN.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i59NUgCP134302; Wed, 9 Jun 2004 19:30:42 -0400 From: Shirley Ma To: davem@redhat.com Subject: [PATCH] some condition check error in ipsec v6 Date: Wed, 9 Jun 2004 16:29:17 -0700 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, xma@us.ibm.com References: <200403311326.43647.mashirle@us.ibm.com> <200405261308.54281.mashirle@us.ibm.com> In-Reply-To: <200405261308.54281.mashirle@us.ibm.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_N15xAnTdM2U6Z4o" Message-Id: <200406091629.17365.mashirle@us.ibm.com> X-archive-position: 5818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1449 Lines: 51 --Boundary-00=_N15xAnTdM2U6Z4o Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is a small patch for condition checking in ah6.c and esp6.c. This patch is against 2.6.6 kernel. -- Thanks Shirley Ma IBM Linux Technology Center --Boundary-00=_N15xAnTdM2U6Z4o Content-Type: text/x-diff; charset="iso-2022-jp"; name="linux-2.6.6-ipsec.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.6-ipsec.patch" diff -urN linux-2.6.6/net/ipv6/ah6.c linux-2.6.6-ipsec/net/ipv6/ah6.c --- linux-2.6.6/net/ipv6/ah6.c 2004-05-09 19:32:53.000000000 -0700 +++ linux-2.6.6-ipsec/net/ipv6/ah6.c 2004-06-09 16:13:26.000000000 -0700 @@ -360,7 +360,7 @@ struct ip_auth_hdr *ah = (struct ip_auth_hdr*)(skb->data+offset); struct xfrm_state *x; - if (type != ICMPV6_DEST_UNREACH || + if (type != ICMPV6_DEST_UNREACH && type != ICMPV6_PKT_TOOBIG) return; diff -urN linux-2.6.6/net/ipv6/esp6.c linux-2.6.6-ipsec/net/ipv6/esp6.c --- linux-2.6.6/net/ipv6/esp6.c 2004-05-09 19:32:52.000000000 -0700 +++ linux-2.6.6-ipsec/net/ipv6/esp6.c 2004-06-09 16:13:38.000000000 -0700 @@ -324,7 +324,7 @@ struct ipv6_esp_hdr *esph = (struct ipv6_esp_hdr*)(skb->data+offset); struct xfrm_state *x; - if (type != ICMPV6_DEST_UNREACH || + if (type != ICMPV6_DEST_UNREACH && type != ICMPV6_PKT_TOOBIG) return; --Boundary-00=_N15xAnTdM2U6Z4o-- From yoshfuji@linux-ipv6.org Wed Jun 9 18:47:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 18:48:04 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A1lsgi030546 for ; Wed, 9 Jun 2004 18:47:54 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8D15133CE5; Thu, 10 Jun 2004 10:48:41 +0900 (JST) Date: Thu, 10 Jun 2004 10:48:41 +0900 (JST) Message-Id: <20040610.104841.48829575.yoshfuji@linux-ipv6.org> To: mashirle@us.ibm.com Cc: davem@redhat.com, netdev@oss.sgi.com, xma@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] some condition check error in ipsec v6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200406091629.17365.mashirle@us.ibm.com> References: <200403311326.43647.mashirle@us.ibm.com> <200405261308.54281.mashirle@us.ibm.com> <200406091629.17365.mashirle@us.ibm.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: 5819 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: 260 Lines: 7 In article <200406091629.17365.mashirle@us.ibm.com> (at Wed, 9 Jun 2004 16:29:17 -0700), Shirley Ma says: > Here is a small patch for condition checking in ah6.c and esp6.c. This patch > is against 2.6.6 kernel. good catch. --yoshfuji From hadi@cyberus.ca Wed Jun 9 18:48:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 18:48:35 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A1mWgi030648 for ; Wed, 9 Jun 2004 18:48:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BYEgB-0002tL-RM for netdev@oss.sgi.com; Wed, 09 Jun 2004 21:48:31 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BYEg5-0007w2-Tf; Wed, 09 Jun 2004 21:48:26 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: jt@hpl.hp.com Cc: netdev@oss.sgi.com In-Reply-To: <20040609174021.GA26159@bougret.hpl.hp.com> References: <20040608184831.GA18462@bougret.hpl.hp.com> <1086722317.1023.18.camel@jzny.localdomain> <20040608195238.GA21089@bougret.hpl.hp.com> <1086728139.1023.71.camel@jzny.localdomain> <20040608220109.GA24536@bougret.hpl.hp.com> <1086752809.1049.62.camel@jzny.localdomain> <20040609174021.GA26159@bougret.hpl.hp.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086832074.1207.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Jun 2004 21:47:54 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5820 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: 2816 Lines: 66 On Wed, 2004-06-09 at 13:40, Jean Tourrilhes wrote: > On Tue, Jun 08, 2004 at 11:46:49PM -0400, jamal wrote: > > > Most likely, the FIFOs will share the same memory pool on the > > > card, so when a FIFO is full, most likely the other FIFOs will be full > > > or close to it. > > > > How do you reach such a conclusion? > > There maybe packets of the same priority for longs periods of time. > > If all the FIFO take from the same memory pool, when one FIFO > is full, it means that the memory pool is exhausted. Is this how these things are designed? > If the memory > pool is exhausted, then you can't fill the other FIFOs. So there are no bounds defined for each FIFO? If yes, whoever designed those boards is on some really cheap crack. Fire his or her ass. If no, then please dont use this approach. Put some limits to the FIFOs and use the strict priority scheme defined (it seems by that standard). > Yep. That's no worse than what we have today with a single > FIFO in today's cards. Remember that amount of buffer on the card is > limited, so we are not talking of an incredible number of packets in > those FIFO. I'm 100% with Andy in suggesting to keep hardware FIFO as > short as possible, precisely so that the TC scheduling is effective. > If you let the card scheduler take over, it will screw up your > TC scheduling no matter what, unless the card scheduler use the exact > same scheduling as TC (which is unlikely for complex TC policies). I am assuming it will use _exactly_ the same prioritization approiach; even if bandwidth allocation is used in the scheduling, the prioritization will match _exactly_ what the NIC does. > If the card policy is to always drain the highest priority > queue first, and you want to guarantee a minimum bandwidth for low > priority traffic at the TC level, if you let the card scheduler do its > business and always feed high priority traffic when it wants it, then > there is no way you can guarantee your minimum bandwidth for low > priority traffic. You can. But the bigger question is do you care? > > No, it's fine only if TC policy is "Always send from highest > priority". If TC policy is different, then it's not fine at all. Not really. Just pick any of the other schedulers which do bwidth scheduling and map the priorities to the FIFO priorities. > You assume that the card scheduler will be configurable, and > work as expected. Wait and see ;-) I am assuming the only thing it can do is strict priority. I trust you know more about how these cards look like - so when you express doubts about the lack of configurability you are also putting doubts in me; but let me say this: If you can have configurability such that you can partition finite FIFOs one for each priority or for a set of priorities, then you are set. cheers, jamal From hadi@cyberus.ca Wed Jun 9 18:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 18:59:44 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A1xdgi031383 for ; Wed, 9 Jun 2004 18:59:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BYEqx-0006WR-KD for netdev@oss.sgi.com; Wed, 09 Jun 2004 21:59:39 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BYEqr-0001PY-9c; Wed, 09 Jun 2004 21:59:33 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, jt@hpl.hp.com In-Reply-To: <200406092127.28477.vkondra@mail.ru> References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406090851.40691.vkondra@mail.ru> <1086780010.1051.106.camel@jzny.localdomain> <200406092127.28477.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086832740.1205.65.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Jun 2004 21:59:01 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5821 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: 1135 Lines: 32 On Wed, 2004-06-09 at 14:27, Vladimir Kondratiev wrote: > Sure. I know when each DMA queue have space to accept new packets. w.r.t Tx > discipline, it is really like 4 (taking into account TSPEC, see my mail about > TGe, minimum 5 for STA and 6 (i did not said about power save buffering) for > AP) independent devices. Vladimir - do you have one of these cards? Jean is putting some my doubts in my mind about their designs. Do they have seperate DMA rings? > I see you got the idea. Question is, how to implement it. As suggested earlier: - introduce id and id_state per ring. - use a skb tag to select id - if ring is full, use same id to requeue to qdisc. - qdiscs above must have semantics that map to the strict priority scheme (eg you could use CBQ which does both priorities and bandwith allocation or use simple prio or strict prio qdiscs). - netif stopping and starting is done per id/ring. Did i miss something? Do you wanna try this? I could give you a hand but dont have much time to code at the moment. I could point you to the different pieces of code that need mods and suggest the changes. cheers, jamal From yoshfuji@linux-ipv6.org Wed Jun 9 19:11:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 19:11:44 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A2Bdgi000538 for ; Wed, 9 Jun 2004 19:11:42 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 510E033CE5; Thu, 10 Jun 2004 11:12:29 +0900 (JST) Date: Thu, 10 Jun 2004 11:12:28 +0900 (JST) Message-Id: <20040610.111228.77019042.yoshfuji@linux-ipv6.org> To: mashirle@us.ibm.com Cc: davem@redhat.com, netdev@oss.sgi.com, xma@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] dst allocation problem in ndisc From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200406091600.30568.mashirle@us.ibm.com> References: <200403311326.43647.mashirle@us.ibm.com> <200405261308.54281.mashirle@us.ibm.com> <200406091600.30568.mashirle@us.ibm.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: 5822 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: 291 Lines: 8 In article <200406091600.30568.mashirle@us.ibm.com> (at Wed, 9 Jun 2004 16:00:29 -0700), Shirley Ma says: > Here is the patch against 2.6.6 kernel. Please review this patch. Basically, I agree. One thing: you can minimize diff using function declaration. --yoshfuji From joubert@berger-family.org Wed Jun 9 19:14:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 19:14:24 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A2EMgi001311 for ; Wed, 9 Jun 2004 19:14:22 -0700 Received: from [192.168.1.20] (c-24-98-113-67.atl.client2.attbi.com[24.98.113.67]) by comcast.net (rwcrmhc11) with SMTP id <20040610012013013009fpife>; Thu, 10 Jun 2004 01:20:13 +0000 Subject: Help with some code From: Joubert Berger To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1086830414.16999.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Jun 2004 21:20:15 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joubert@berger-family.org Precedence: bulk X-list: netdev Content-Length: 5223 Lines: 124 I am trying to write a routine that will allow me to send a reset packet with some additional status information. The routine below seems to be able to ok as it sends the newly created skbuff to ip_finish_output(). But after that the kernel panics. Could I get someone to look over this and see what I might be doing wrong? --joubert void SendTcpRst(struct sk_buff *oskb, int status) { struct sk_buff *nskb; struct iphdr *oiph, *iph; struct my_tcp_reset tcp_reset, *my_reset_ptr; struct tcphdr *otcph, *tcph; struct ethhdr *oeth, *eth; unsigned char *ohdr; unsigned int iplen; struct rtable *rt; int ret; if (!oskb) return; oeth = oskb->mac.ethernet; oiph = oskb->nh.iph; otcph = (struct tcphdr *) ((u_int32_t*)oskb->nh.iph + oskb->nh.iph->ihl); if (ip_route_output(&rt, oskb->nh.iph->saddr, oskb->nh.iph->daddr , RT_TOS(oskb->nh.iph->tos) | RTO_CONN, 0) != 0) { printk(("no route to host\n")); return; } tcp_reset.status = htonl(status); nskb = alloc_skb(16 + sizeof(struct iphdr) + sizeof(struct tcphdr) + sizeof(struct my_tcp_reset), GFP_ATOMIC); if (!nskb) return; skb_reserve(nskb, 16); eth = (struct ethhdr *) skb_push(nskb, sizeof(struct ethhdr)); iph = (struct iphdr *) skb_put(nskb, sizeof(struct iphdr)); tcph = (struct tcphdr *) skb_put(nskb, sizeof(struct tcphdr)); my_reset_ptr = (struct my_tcp_reset *) skb_put(nskb, sizeof(struct my_tcp_reset)); memcpy(my_reset_ptr, &tcp_reset, sizeof(struct my_tcp_reset)); /* Populate new ethernet frame */ printk("copy ethernet frame\n"); memcpy(eth->h_dest, oeth->h_source, ETH_ALEN); memcpy(eth->h_source, oeth->h_dest, ETH_ALEN); eth->h_proto = oeth->h_proto; /* Populate new TCP frame */ printk("copy TCP frame\n"); tcph->seq = 0; tcph->ack_seq = htonl(ntohl(otcph->seq) + 1); ((u_int8_t *)tcph)[13] = 0; tcph->rst = 1; tcph->ack = 0; tcph->window = 0; tcph->urg_ptr = 0; tcph->check = 0; tcph->doff = sizeof(struct tcphdr)/4; tcph->check = tcp_v4_check(tcph, sizeof(struct tcphdr), nskb->nh.iph->saddr, nskb->nh.iph->daddr, csum_partial((char *)tcph, sizeof(struct tcphdr), 0)); /* Populate new IP frame */ printk("copy IP frame\n"); iph->ihl = 5; iph->version = 4; iph->ttl = MAXTTL; iph->tos = 0; iph->id = 0; iph->protocol = IPPROTO_TCP; iph->saddr = oiph->daddr; iph->daddr = oiph->saddr; iph->frag_off = htons(IP_DF); iplen = sizeof(struct iphdr) + sizeof(struct tcphdr) + sizeof(struct my_tcp_reset); iph->tot_len = htons(iplen); iph->check = 0; iph->tot_len = htons(iplen); iph->check = 0; iph->check = ip_fast_csum((void *) iph, iph->ihl); /* Populate skb info */ printk("copy SKB\n"); nskb->priority = 0; nskb->dst = dst_clone(&rt->u.dst); nskb->dev = nskb->dst->dev; nskb->h.th = tcph; nskb->nh.iph = iph; nskb->mac.ethernet = eth; nskb->protocol = oskb->protocol; nskb->ip_summed = oskb->ip_summed; nskb->stamp = oskb->stamp; nskb->pkt_type = PACKET_HOST; nskb->nfct = NULL; nskb->nfcache = 0; nskb->nfmark = 0; nskb->cloned = 0; atomic_set(&nskb->users, 1); /* Deliver packet now */ printk("TEST: SRC=%u.%u.%u.%u DST=%u.%u.%u.%u \n", NIPQUAD(iph->saddr), NIPQUAD(iph->daddr)); ret = ip_finish_output(nskb); printk("TEST: ret=%d\n", ret); } From horms@koto.vergenet.net Wed Jun 9 21:09:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 21:09:53 -0700 (PDT) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A49ogi010779 for ; Wed, 9 Jun 2004 21:09:50 -0700 Received: (qmail 13425 invoked by uid 7100); 10 Jun 2004 04:05:16 -0000 Date: Thu, 10 Jun 2004 11:45:37 +0900 From: Horms To: netdev@oss.sgi.com, Vladimir Kondratiev Subject: Re: in-driver QoS Message-ID: <20040610024536.GB17334@verge.net.au> Mail-Followup-To: netdev@oss.sgi.com, Vladimir Kondratiev References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406090851.40691.vkondra@mail.ru> <1086780010.1051.106.camel@jzny.localdomain> <200406092127.28477.vkondra@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406092127.28477.vkondra@mail.ru> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@verge.net.au Precedence: bulk X-list: netdev Content-Length: 551 Lines: 15 On Wed, Jun 09, 2004 at 09:27:28PM +0300, Vladimir Kondratiev wrote: > > > > Indeed. > > Looking at the transmit path code it seems doable. > > for each dev->id you also maintain a dev->id_state. > > We either use skb->fwmark or skb->priority to map to the different > BTW, what is fwmark? in 2.6.6 it is not present. The name in the kernel was changed to nfmark a while ago. Though is seems to be still referenced as fwmark quite a lot in documentation. I believe its primary use is for the mark target and match in netfilter/iptables. -- Horms From rl@hellgate.ch Wed Jun 9 21:33:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 21:33:47 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A4XVgi011597 for ; Wed, 9 Jun 2004 21:33:31 -0700 Received: from k3.hellgate.ch (81.62.85.19) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A68002C2126; Mon, 7 Jun 2004 11:59:22 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id EBDDC471EE2; Mon, 7 Jun 2004 13:59:21 +0200 (CEST) Date: Mon, 7 Jun 2004 13:59:21 +0200 From: Roger Luethi To: David Dillow Cc: Jeff Garzik , Andrew Morton , Netdev Subject: Re: [0/3] mc_filter on big-endian arch Message-ID: <20040607115921.GB32569@k3.hellgate.ch> References: <20040606165322.GA13247@k3.hellgate.ch> <1086575392.4731.9.camel@ori.thedillows.org> <20040607114832.GA32569@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607114832.GA32569@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 284 Lines: 11 One thing maybe worth mentioning: If you want to play with different addresses, remember that IP addresses are in decimal notation, ethernet in hex. So if you set target# ip maddr add 01:00:5e:00:00:25 dev eth0 the test would be tester# ping -r -I eth0 -t 1 -c 2 224.0.0.37 Roger From dlstevens@us.ibm.com Wed Jun 9 22:10:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 22:10:16 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A5A9gk013512 for ; Wed, 9 Jun 2004 22:10:12 -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.2) with ESMTP id i5A59uqF640200; Thu, 10 Jun 2004 01:09:56 -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 i5A59uTm326644; Wed, 9 Jun 2004 23:09:56 -0600 In-Reply-To: <20040607115921.GB32569@k3.hellgate.ch> To: Roger Luethi Cc: Andrew Morton , David Dillow , Jeff Garzik , Netdev , netdev-bounce@oss.sgi.com MIME-Version: 1.0 Subject: Re: [0/3] mc_filter on big-endian arch X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 9 Jun 2004 23:09:53 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/09/2004 23:09:56, Serialize complete at 06/09/2004 23:09:56 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 5827 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: 791 Lines: 22 netdev-bounce@oss.sgi.com wrote on 06/07/2004 04:59:21 AM: > One thing maybe worth mentioning: If you want to play with different > addresses, remember that IP addresses are in decimal notation, ethernet > in hex. So if you set > target# ip maddr add 01:00:5e:00:00:25 dev eth0 > the test would be > tester# ping -r -I eth0 -t 1 -c 2 224.0.0.37 This will add "01:00:5e:00:00:25" to the device multicast address filter, which will mean the host will receive the packet. But because it doesn't join the group at the IP level, it'll be dropped and the ping won't be answered (it isn't for a local address). If you want the machine to answer, you need to join the group, which will conveniently add the hardware multicast address automatically. :-) +-DLS From rl@hellgate.ch Wed Jun 9 22:09:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 22:09:43 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A59cgi013485 for ; Wed, 9 Jun 2004 22:09:38 -0700 Received: from k3.hellgate.ch (83.77.17.159) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD3003125CE; Tue, 8 Jun 2004 21:08:10 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id D147025D1E; Tue, 8 Jun 2004 23:08:09 +0200 (CEST) Date: Tue, 8 Jun 2004 23:08:09 +0200 From: Roger Luethi To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics Message-ID: <20040608210809.GA10542@k3.hellgate.ch> Mail-Followup-To: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607145723.41da5783.davem@redhat.com> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 923 Lines: 22 On Mon, 07 Jun 2004 14:57:23 -0700, David S. Miller wrote: > On Mon, 7 Jun 2004 23:28:04 +0200 > Roger Luethi wrote: > > > What is the correct response if a user passes ethtool speed or duplex > > arguments while autoneg is on? Some possible answers are: > > [...] > speed and duplex fields should be silently ignored in this case It may not matter much because few people care about forced media these days. And it is debatable whether trying to guess the users intention is a good idea (we lack means for users to manipulate autoneg results via advertisted values but that's no big deal). However, "silently ignoring" strikes me as a very poor choice, in stark contrast to Unix/Linux tradition. A user issues a command which cannot be executed and gets the same response that is used to indicate success!? What school of user interface design is that? How is that not confusing users? Roger From dlstevens@us.ibm.com Wed Jun 9 22:45:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 22:45:51 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A5jhgi014914 for ; Wed, 9 Jun 2004 22:45: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.2) with ESMTP id i5A5jSqF337220; Thu, 10 Jun 2004 01:45:28 -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 i5A5jRTm328802; Wed, 9 Jun 2004 23:45:27 -0600 In-Reply-To: To: David Stevens Cc: Andrew Morton , David Dillow , Jeff Garzik , Netdev , Roger Luethi MIME-Version: 1.0 Subject: Re: [0/3] mc_filter on big-endian arch X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 9 Jun 2004 22:45:26 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/09/2004 23:45:27, Serialize complete at 06/09/2004 23:45:27 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 5828 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: 1618 Lines: 51 PS - Here's a trivial program that will join a group. If you run this on one side, then a ping to the multicast address will work when it's in the group, and stop answering when it exits. There are more general things that have been around for years for testing-- I just threw this together just now. (I hope it doesn't have any bugs! :-) ) Should be suitable for testing hardware multicast address filters... +-DLS #include #include int main(int argc, char *argv[]) { struct ip_mreqn mreqn; int s; if (argc != 3) { fprintf(stderr, "usage: %s \n", argv[0]); exit(1); } s = socket(PF_INET, SOCK_DGRAM, 0); if (s < 0) { perror("socket"); exit(1); } memset(&mreqn, 0, sizeof(mreqn)); mreqn.imr_ifindex = if_nametoindex(argv[1]); if (!mreqn.imr_ifindex) { fprintf(stderr, "%s: \"%s\" invalid interface\n", argv[0], argv[1]); exit(1); } if (inet_pton(AF_INET, argv[2], &mreqn.imr_multiaddr) <= 0) { fprintf(stderr, "%s: \"%s\" invalid group address\n", argv[0], argv[2]); exit(1); } if (setsockopt(s, SOL_IP, IP_ADD_MEMBERSHIP, &mreqn,sizeof mreqn) < 0) { perror("IP_ADD_MEMBERSHIP"); exit(1); } printf("joined group %s on %s (pausing...)"); fflush(stdout); pause(); exit(0); } From felipe_alfaro@linuxmail.org Wed Jun 9 23:07:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jun 2004 23:07:33 -0700 (PDT) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A67Ngi015606 for ; Wed, 9 Jun 2004 23:07:26 -0700 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id E5DBF42D1B; Thu, 10 Jun 2004 08:07:10 +0200 (CEST) Subject: Re: 2.6.7-rc3: waiting for eth0 to become free From: Felipe Alfaro Solana To: Christian Kujau Cc: Felipe Alfaro Solana , NetDev Mailinglist , Kernel Mailinglist In-Reply-To: <40C793CE.6000609@g-house.de> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> <1086794282.1706.2.camel@teapot.felipe-alfaro.com> <40C793CE.6000609@g-house.de> Content-Type: text/plain Date: Thu, 10 Jun 2004 08:07:16 +0200 Message-Id: <1086847636.1719.6.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 (1.5.9.1-2) Content-Transfer-Encoding: 7bit X-archive-position: 5829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: netdev Content-Length: 2138 Lines: 48 On Thu, 2004-06-10 at 00:48 +0200, Christian Kujau wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Felipe Alfaro Solana wrote: > |>What is happening is that some subsystem is holding a reference to the > device (calling dev_hold()) > |>but not cleaning up (calling dev_put). It can be a hard to track > which of the many > |>things routing, etc are not being cleared properly. Look for routes > that still > |>get stuck (ip route) and neighbor cache entries. Most of these end up > being > |>protocol bugs. > | > | > | The two attached patches, one for net/ipv4/route.c, the other for net/ > | ipv6/route.c fix all my problems when running "cardctl eject" while a > | program mantains an open network socket (ESTABLISHED). > | > | Both patches apply cleanly against 2.6.7-rc3 and 2.6.7-rc3-mm1. > | I'm not completely sure what has changed in 2.6.7-rc3 that is breaking > | cardctl for me, as it Just Worked(TM) fine in 2.6.7-rc2. > > do you know, by any chance, if this error is dependent to eth0 only or > could help for my error message too: > > unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 I think the mentioned error is not dependent on any specific interface (let it be eth0, or ppp0), but any interface in general which has a routing entry and is the target/source of IP traffic. This is based on the fact that my fixes play with the refcounting on any interface. not just eth0 specifically, and pertain to both IPv4 and IPv6 core. However, I detected this behavior on my eth0, since this is the only interface I have on my laptop. You just can try both patches against 2.6.7-rc3 or 2.6.7-rc3-mm1 to see if them cure your problems. > happened just a few hours ago (2.6.7-rc3), i had to reboot the box > anyway, but pppd was not able to die (even with kill -9) In my case, I was able to trigger the problem by running "cardctl eject" which was then stuck at D state. Killing any program using a network socket, and waiting for opened connections to transition from ESTABLISHED to TIME_WAIT and then being closed, allowed "cardctl" to exit the D state. From vkondra@mail.ru Thu Jun 10 01:25:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 01:26:01 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5A8Pegi023162 for ; Thu, 10 Jun 2004 01:25:41 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 818151CC9AC for ; Thu, 10 Jun 2004 09:56:53 +0400 (MSD) Received: from [81.218.179.11] (port=43541 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BYIXV-0006vC-00; Thu, 10 Jun 2004 09:55:50 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: in-driver QoS Date: Thu, 10 Jun 2004 08:55:31 +0300 User-Agent: KMail/1.6.2 Cc: jt@hpl.hp.com References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406092127.28477.vkondra@mail.ru> <1086832740.1205.65.camel@jzny.localdomain> In-Reply-To: <1086832740.1205.65.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406100855.37348.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5A8Pegi023162 X-archive-position: 5830 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: 1936 Lines: 50 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 10 June 2004 04:59, jamal wrote: > On Wed, 2004-06-09 at 14:27, Vladimir Kondratiev wrote: > > Sure. I know when each DMA queue have space to accept new packets. w.r.t > > Tx discipline, it is really like 4 (taking into account TSPEC, see my > > mail about TGe, minimum 5 for STA and 6 (i did not said about power save > > buffering) for AP) independent devices. > > Vladimir - do you have one of these cards? Jean is putting some my > doubts in my mind about their designs. Do they have seperate DMA rings? Good question. Until I can really answer, let's say "in theory, all next generation wireless cards should have similar design". Hint: I have also mail ending by intel.com > > > I see you got the idea. Question is, how to implement it. > > As suggested earlier: > - introduce id and id_state per ring. > - use a skb tag to select id skb->priority, correct? > - if ring is full, use same id to requeue to qdisc. how? > - qdiscs above must have semantics that map to the strict priority > scheme (eg you could use CBQ which does both priorities and bandwith > allocation or use simple prio or strict prio qdiscs). > - netif stopping and starting is done per id/ring. how to do it? I am afraid several network interfaces is not a good idea. > > Did i miss something? Sounds good. Next step is integrated service, where, prior to use some priority, STA have to allocate bandwidth and get admission from AP. > > Do you wanna try this? I could give you a hand but dont have much time > to code at the moment. I could point you to the different pieces of code > that need mods and suggest the changes. It would be great help. Please... I promise to share results. > > cheers, > jamal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAx/fZqxdj7mhC6o0RAv/6AJ9r0zqZN8E1Y6UFUBH+0Ikfl6yRPQCgqhCJ OmLUtIXWDjtI8RpQcsUvQJ0= =agJJ -----END PGP SIGNATURE----- From evil@g-house.de Thu Jun 10 04:06:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 04:08:04 -0700 (PDT) Received: from mail.g-house.de (ns1.g-housing.de [62.75.136.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AB6wgi030410 for ; Thu, 10 Jun 2004 04:06:59 -0700 Received: from g14d8.g.pppool.de ([80.185.20.216] helo=sheep.housecafe.de) by mail.g-house.de with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1BYNQS-0001Ux-GO; Thu, 10 Jun 2004 13:08:52 +0200 Received: from prinz.housecafe.de ([192.168.1.11]) by sheep.housecafe.de with esmtp (Exim 4.34) id 1BYNOS-0004KY-Pn; Thu, 10 Jun 2004 13:06:48 +0200 Message-ID: <40C840C8.8000605@g-house.de> Date: Thu, 10 Jun 2004 13:06:48 +0200 From: Christian Kujau User-Agent: Mozilla Thunderbird 0.6 (X11/20040605) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felipe Alfaro Solana CC: NetDev Mailinglist , Kernel Mailinglist Subject: Re: 2.6.7-rc3: waiting for eth0 to become free References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> <1086794282.1706.2.camel@teapot.felipe-alfaro.com> <40C793CE.6000609@g-house.de> <1086847636.1719.6.camel@teapot.felipe-alfaro.com> In-Reply-To: <1086847636.1719.6.camel@teapot.felipe-alfaro.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: evil@g-house.de Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 35 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felipe Alfaro Solana wrote: | I think the mentioned error is not dependent on any specific interface | (let it be eth0, or ppp0), but any interface in general which has a | routing entry and is the target/source of IP traffic. This is based on | the fact that my fixes play with the refcounting on any interface. not | just eth0 specifically, and pertain to both IPv4 and IPv6 core. ok. | In my case, I was able to trigger the problem by running "cardctl eject" | which was then stuck at D state. Killing any program using a network | socket, and waiting for opened connections to transition from | ESTABLISHED to TIME_WAIT and then being closed, allowed "cardctl" to | exit the D state. no having pcmcia here, i'll see if i can reproduce it to / see what the patches will do. Thanks for the explanation, Christian. - -- BOFH excuse #439: Hot Java has gone cold -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAyEDH+A7rjkF8z0wRAusDAKCp2WW4LO01hP9ZDXa3N6eH7cuvIgCg2dTz IzprZryuJ/VuiRY/DGvMH24= =f7qL -----END PGP SIGNATURE----- From rl@hellgate.ch Thu Jun 10 05:59:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 05:59:50 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ACxbgi004565 for ; Thu, 10 Jun 2004 05:59:38 -0700 Received: from k3.hellgate.ch (62.203.86.177) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD30033BD76; Wed, 9 Jun 2004 21:38:51 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 7D25F547D09; Wed, 9 Jun 2004 23:38:50 +0200 (CEST) Date: Wed, 9 Jun 2004 23:38:50 +0200 From: Roger Luethi To: Bill Davidsen Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics Message-ID: <20040609213850.GA17243@k3.hellgate.ch> Mail-Followup-To: Bill Davidsen , "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> <40C77C70.5070409@tmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C77C70.5070409@tmr.com> X-Operating-System: Linux 2.6.7-rc3-bk1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1591 Lines: 35 On Wed, 09 Jun 2004 17:09:04 -0400, Bill Davidsen wrote: > cases forcing on both ends or just the NIC end results in a fully > functional connection. > > We usually do this with module parameters, but do use ethtool (or > mii-tool) on occasion. I just killed the module parameters in my via-rhine development tree. I suppose you don't use via-rhine!? :-) Nobody complained when the code was broken for the longest time, and the current design has all kinds of issues, not the least of which is a distinct lack of sane semantics for stuff like hotplug, interface renaming, etc. I'd prefer not to spend my time writing a clean implementation (or fixing up the current one) of a mechanism that is conceptually obsolete. > >However, "silently ignoring" strikes me as a very poor choice, in > >stark contrast to Unix/Linux tradition. A user issues a command which > >cannot be executed and gets the same response that is used to indicate > >success!? What school of user interface design is that? How is that > >not confusing users? > > Yah. > > Seeing this happen while autonegotiation is in progress is a small and > unlikely window of course! Hmm? It's not about autoneg being in progress, and it's not a race of any kind. If your NIC comes up with nway autoneg enabled, you must use ethtool to explicitly turn autoneg off before you can use ethtool duplex/speed options to force a media mode. However, if you try to force media with autoneg still enabled, your command will be silently ignored. It's up to the user to find out that the command failed and why. Roger From dave@thedillows.org Thu Jun 10 06:38:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 06:38:17 -0700 (PDT) Received: from iasrv1.idleaire.net (NS1.idleaire.net [65.220.16.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ADc7gi006039 for ; Thu, 10 Jun 2004 06:38:08 -0700 Received: by iasrv1.idleaire.net (Postfix, from userid 300) id DB548236E74; Thu, 10 Jun 2004 09:38:01 -0400 (EDT) Received: from corp4.idleaire.com (corp4.idleaire.com [10.1.66.36]) by iasrv1.idleaire.net (Postfix) with ESMTP id 0801C236E70; Thu, 10 Jun 2004 09:38:00 -0400 (EDT) Received: from knox.voodoobox.net ([10.1.66.124]) by corp4.idleaire.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Jun 2004 09:38:00 -0400 Subject: Re: [0/3] mc_filter on big-endian arch From: Dave Dillow To: Roger Luethi Cc: David Stevens , Andrew Morton , Jeff Garzik , Netdev In-Reply-To: <20040610102045.GA11616@k3.hellgate.ch> References: <20040607115921.GB32569@k3.hellgate.ch> <20040610102045.GA11616@k3.hellgate.ch> Content-Type: text/plain Message-Id: <1086874679.23004.17.camel@dillow.idleaire.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 10 Jun 2004 09:37:59 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2004 13:38:00.0006 (UTC) FILETIME=[256A5660:01C44EF0] X-archive-position: 5833 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: 1036 Lines: 22 On Thu, 2004-06-10 at 06:20, Roger Luethi wrote: > Multicast Driver Testing Quick How-To (version 0.2) > ===================================== Thank you guys for all the info. I've done some testing, and sure enough, there are some problems in typhoon, which I'll fix this weekend. But I think the cpu_to_le32() calls are correct -- it would seem that crc32_be() is needed rather than ether_crc() (which does little endian). I'm assuming the results will be different, but I haven't done the math, nor am I very familiar with the properties of the crc. Even then, I'm not sure that's my real problem -- if it was setting the wrong bits in the hash -- my working hypothesis -- I shouldn't be receiving the 224.0.0.1 frames. I am. I am also seeing 224.1.1.37 frames come up the stack in tcpdump (with -p), before running "ip maddr ..." so something seems wonky. It seems to be getting into ALL_MULTI mode, but I don't see how in the driver. I'm going to add some printks and see what's going on. -- Dave Dillow From shemminger@osdl.org Thu Jun 10 08:36:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 08:37:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AFaxgi013018 for ; Thu, 10 Jun 2004 08:36:59 -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 i5AFaqr07893; Thu, 10 Jun 2004 08:36:52 -0700 Date: Thu, 10 Jun 2004 08:36:52 -0700 From: Stephen Hemminger To: Felipe Alfaro Solana Cc: NetDev Mailinglist , Kernel Mailinglist Subject: Re: 2.6.7-rc3: waiting for eth0 to become free Message-Id: <20040610083652.6f3ba3a6@dell_ss3.pdx.osdl.net> In-Reply-To: <1086794282.1706.2.camel@teapot.felipe-alfaro.com> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> <1086794282.1706.2.camel@teapot.felipe-alfaro.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: 5834 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: 2665 Lines: 55 On Wed, 09 Jun 2004 17:18:02 +0200 Felipe Alfaro Solana wrote: > On Tue, 2004-06-08 at 14:02 -0700, Stephen Hemminger wrote: > > On Tue, 08 Jun 2004 22:09:29 +0200 > > Felipe Alfaro Solana wrote: > > > > > On Tue, 2004-06-08 at 12:42 -0700, Stephen Hemminger wrote: > > > > On Tue, 08 Jun 2004 21:18:30 +0200 > > > > Felipe Alfaro Solana wrote: > > > > > > > > > Hi! > > > > > > > > > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > > > > > "cardctl eject" so the system won't freeze when resuming. "cardctl > > > > > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > > > > > network sockets opened (for example, Evolution mantaining a connection > > > > > against an IMAP server): the card is ejected (well, not physically), > > > > > even when there are ESTABLISHED connections. > > > > > > > > > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > > > > > holds any socket open. After a while the "unregister_netdevice: waiting > > > > > for eth0 to become free" message starts appearing on the kernel message > > > > > ring. The only apparent solution is killing that program, ejecting the > > > > > card from its slot and wait until 3c59x.o usage count reaches zero. > > > > > > > > > > Can someone tell me what's going on here? > > > > > Thank you very much. > > > > > > > > What protocols are you running? Is IPV6 loaded? > > > > > > I'm using IPv4, IPv6 and IPSec ESP with AES/CBC. > > > Do you want .config? > > > > Not really, could you see if it is an IPv6 vs IPSec problem by not running/loading > > one or the other. > > > > What is happening is that some subsystem is holding a reference to the device (calling dev_hold()) > > but not cleaning up (calling dev_put). It can be a hard to track which of the many > > things routing, etc are not being cleared properly. Look for routes that still > > get stuck (ip route) and neighbor cache entries. Most of these end up being > > protocol bugs. > > The two attached patches, one for net/ipv4/route.c, the other for net/ > ipv6/route.c fix all my problems when running "cardctl eject" while a > program mantains an open network socket (ESTABLISHED). > > Both patches apply cleanly against 2.6.7-rc3 and 2.6.7-rc3-mm1. > I'm not completely sure what has changed in 2.6.7-rc3 that is breaking > cardctl for me, as it Just Worked(TM) fine in 2.6.7-rc2. > > Hope this can throw some light at this issue. Since you effectively remove rth->idev, why not remove it from the structure to make sure no code is still expecting it to be set. From rajuraghava@yahoo.com Thu Jun 10 10:41:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 10:41:27 -0700 (PDT) Received: from web20209.mail.yahoo.com (web20209.mail.yahoo.com [216.136.226.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AHfMgi018338 for ; Thu, 10 Jun 2004 10:41:24 -0700 Message-ID: <20040610174121.9243.qmail@web20209.mail.yahoo.com> Received: from [66.127.235.89] by web20209.mail.yahoo.com via HTTP; Thu, 10 Jun 2004 10:41:21 PDT Date: Thu, 10 Jun 2004 10:41:21 -0700 (PDT) From: Raghava Vatsavayi Subject: register_netdev usage To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rajuraghava@yahoo.com Precedence: bulk X-list: netdev Content-Length: 707 Lines: 29 Hi, Please clarify any issues with register_netdev usage. Like I have seen strange behaviour with 2.6.5-7 kernel on PPC64 platform in my network driver: When register_netdev is not called at the end of my probe function s2io_init_nic but some where in middle of probe function, then s2io_open gets called even though I was just doing insmod. But this issue goes away when I push register_netdev to the end of probe function. So why is it like this, is this expected behaviour??? Please mail me at rajuraghava@yahoo.com as I didt subscribe. Regards Raghava. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From diegocg@teleline.es Thu Jun 10 10:43:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 10:43:32 -0700 (PDT) Received: from tsmtp3.ldap.isp (smtp.terra.es [213.4.129.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AHhOgi018565 for ; Thu, 10 Jun 2004 10:43:27 -0700 Received: from estel ([80.103.30.78]) by tsmtp3.ldap.isp (terra.es) with ESMTP id HZ3T8A01.W5R; Thu, 10 Jun 2004 19:43:22 +0200 Date: Thu, 10 Jun 2004 19:43:21 +0200 From: Diego Calleja =?ISO-8859-15?Q?Garc=EDa?= To: Felipe Alfaro Solana Cc: shemminger@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.7-rc3: waiting for eth0 to become free Message-Id: <20040610194321.7c67c854.diegocg@teleline.es> In-Reply-To: <1086794282.1706.2.camel@teapot.felipe-alfaro.com> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> <1086794282.1706.2.camel@teapot.felipe-alfaro.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5AHhOgi018565 X-archive-position: 5836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: diegocg@teleline.es Precedence: bulk X-list: netdev Content-Length: 2511 Lines: 60 El Wed, 09 Jun 2004 17:18:02 +0200 Felipe Alfaro Solana escribi: I'm seeing the same with a ppp link: pppd can't be killed even with SIGKILL (it eats 100% of cpu - all in sys time, readprofile attached) and the kernel spits out those messages: unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 etc... It doesn't happen always. i've seen it a couple of times, right now I'm trying to reproduce it with the patch felipe provided (this is plain -rc3 too) This is the trace of the looping pppd: pppd S C140E820 0 721 1 18063 17268 (NOTLB) 004d8032 7a6e2f0b 00000f8c c140e820 00000001 ddce8170 dd749e18 dd749e18 00000000 00000001 c032bc08 0000000a dd749e64 c011f454 00000046 00000001 c03500a4 00000046 c03500a8 c0110f66 ddce8170 ddce8170 010bdf60 dd749eec Call Trace: [] __do_softirq+0xb4/0xc0 [] smp_apic_timer_interrupt+0xe6/0x150 [] apic_timer_interrupt+0x1a/0x20 [] schedule+0x71/0x640 [] apic_timer_interrupt+0x1a/0x20 [] process_timeout+0x0/0x10 [] del_singleshot_timer_sync+0x8/0x30 [] schedule_timeout+0x69/0xc0 [] common_interrupt+0x18/0x20 [] process_timeout+0x0/0x10 [] netdev_wait_allrefs+0x55/0x110 [] netdev_run_todo+0x12c/0x240 [] ppp_asynctty_close+0x0/0x100 [ppp_async] [] ppp_shutdown_interface+0x8b/0xf0 [ppp_generic] [] ppp_release+0x52/0x60 [ppp_generic] [] __fput+0x106/0x120 [] filp_close+0x4f/0x80 [] sysenter_past_esp+0x52/0x71 profile (it's a dual box, the bug only keeps 100% one cpu, i reseted the profile and let it run 5-10 seconds before getting this) 23165 total 0,0134 11517 default_idle 179,9531 4099 schedule 2,5619 3572 __mod_timer 6,3786 1867 del_timer 11,6687 1202 sched_clock 8,3472 508 schedule_timeout 2,6458 194 netdev_wait_allrefs 0,7132 157 del_singleshot_timer_sync 3,2708 13 __copy_user_intel 0,0739 Diego Calleja From scott.feldman@intel.com Thu Jun 10 11:19:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 11:19:10 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AIJ6gi019764 for ; Thu, 10 Jun 2004 11:19:06 -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 i5AIJcJe014098; Thu, 10 Jun 2004 18:19:40 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5AIJrp4028510; Thu, 10 Jun 2004 18:19:54 GMT Received: from sfeldma-ich5.jf.intel.com ([134.134.3.54]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061011185608040 ; Thu, 10 Jun 2004 11:18:56 -0700 Date: Thu, 10 Jun 2004 11:16:32 -0700 (PDT) From: Scott Feldman To: jgarzik@pobox.com cc: netdev@oss.sgi.com, scott.feldman@intel.com Subject: [PATCH 2.6 1/3] e100: stepping over err return code Message-ID: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 5837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 876 Lines: 22 * Spotted by Jay Vosburgh [fubar@us.ibm.com]. err return code was getting stepped on in the case where we need to report low or no cb resources, which in turn messed up the netif_stop_queue logic in xmit_frame. Signed-off by: scott.feldman@intel.com -------- --- linux-2.5/drivers/net/e100.c 2004-06-10 11:06:03.457155768 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-06-10 11:06:59.105695904 -0700 @@ -827,8 +827,8 @@ static inline int e100_exec_cb(struct ni cb->prev->command &= cpu_to_le16(~cb_s); while(nic->cb_to_send != nic->cb_to_use) { - if(unlikely((err = e100_exec_cmd(nic, nic->cuc_cmd, - nic->cb_to_send->dma_addr)))) { + if(unlikely(e100_exec_cmd(nic, nic->cuc_cmd, + nic->cb_to_send->dma_addr))) { /* Ok, here's where things get sticky. It's * possible that we can't schedule the command * because the controller is too busy, so From scott.feldman@intel.com Thu Jun 10 11:23:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 11:24:14 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AINwgi020148 for ; Thu, 10 Jun 2004 11:23:58 -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 i5AIOAJe015991; Thu, 10 Jun 2004 18:24:30 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5AIOtaX028820; Thu, 10 Jun 2004 18:24:55 GMT Received: from sfeldma-ich5.jf.intel.com ([134.134.3.54]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061011232417824 ; Thu, 10 Jun 2004 11:23:24 -0700 Date: Thu, 10 Jun 2004 11:21:00 -0700 (PDT) From: Scott Feldman To: jgarzik@pobox.com cc: netdev@oss.sgi.com, scott.feldman@intel.com Subject: [PATCH 2.6 2/3] e100: fix skb leak in tx timeout Message-ID: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 5838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 1086 Lines: 32 * If e100 experiences a transmit timeout, and the tx ring is completely full at the time, it will leak all of the skbs on the tx ring (because extra logic is needed to distinguish ring full from ring empty). Jay Vosburgh [fubar@us.ibm.com]. Signed-off by: scott.feldman@intel.com ----------- --- linux-2.5/drivers/net/e100.c 2004-06-10 11:07:00.015557584 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-06-10 11:07:18.487749384 -0700 @@ -1323,7 +1323,7 @@ static inline int e100_tx_clean(struct n static void e100_clean_cbs(struct nic *nic) { if(nic->cbs) { - while(nic->cb_to_clean != nic->cb_to_use) { + while(nic->cbs_avail != nic->params.cbs.count) { struct cb *cb = nic->cb_to_clean; if(cb->skb) { pci_unmap_single(nic->pdev, @@ -1333,8 +1333,8 @@ static void e100_clean_cbs(struct nic *n dev_kfree_skb(cb->skb); } nic->cb_to_clean = nic->cb_to_clean->next; + nic->cbs_avail++; } - nic->cbs_avail = nic->params.cbs.count; pci_free_consistent(nic->pdev, sizeof(struct cb) * nic->params.cbs.count, nic->cbs, nic->cbs_dma_addr); From scott.feldman@intel.com Thu Jun 10 11:28:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 11:28:39 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AISIgi020503 for ; Thu, 10 Jun 2004 11:28:18 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) 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 i5AIT7A8009834; Thu, 10 Jun 2004 18:29:10 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5AIQgpe000917; Thu, 10 Jun 2004 18:29:00 GMT Received: from sfeldma-ich5.jf.intel.com ([134.134.3.54]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061011280209568 ; Thu, 10 Jun 2004 11:28:03 -0700 Date: Thu, 10 Jun 2004 11:25:39 -0700 (PDT) From: Scott Feldman To: jgarzik@pobox.com cc: netdev@oss.sgi.com, scott.feldman@intel.com Subject: [PATCH 2.6 3/3] e100: fix sender hang after tx timeout Message-ID: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 5839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 998 Lines: 31 * When e100 experiences a transmit timeout, it calls e100_up() to reset the device. e100_up calls netif_start_queue to release any flow block, but doesn't reschedule. This patch unblocks the flow and schedules Tx. Jay Vosburgh [fubar@us.ibm.com]. Signed-off by: scott.feldman@intel.com ------------- --- linux-2.5/drivers/net/e100.c 2004-06-10 11:07:18.954678400 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-06-10 11:07:35.224205056 -0700 @@ -1659,17 +1659,16 @@ static int e100_up(struct nic *nic) goto err_clean_cbs; e100_set_multicast_list(nic->netdev); e100_start_receiver(nic); - netif_start_queue(nic->netdev); mod_timer(&nic->watchdog, jiffies); if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) goto err_no_irq; e100_enable_irq(nic); + netif_wake_queue(nic->netdev); return 0; err_no_irq: del_timer_sync(&nic->watchdog); - netif_stop_queue(nic->netdev); err_clean_cbs: e100_clean_cbs(nic); err_rx_clean_list: From xma@us.ibm.com Thu Jun 10 13:06:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 13:06:04 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AK5tgi026839 for ; Thu, 10 Jun 2004 13:06:02 -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.2) with ESMTP id i5AK5dxp449530; Thu, 10 Jun 2004 16:05:39 -0400 Received: from d03nm124.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 i5AK5cK3281576; Thu, 10 Jun 2004 14:05:38 -0600 In-Reply-To: <20040610.111228.77019042.yoshfuji@linux-ipv6.org> To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, mashirle@us.ibm.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] dst allocation problem in ndisc X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Shirley Ma Date: Thu, 10 Jun 2004 14:05:35 -0600 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/10/2004 14:05:38 Content-Type: multipart/mixed; boundary="=_mixed 006E543B07256EAF_=" X-archive-position: 5840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3390 Lines: 72 --=_mixed 006E543B07256EAF_= Content-Type: multipart/alternative; boundary="=_alternative 006E543B07256EAF_=" --=_alternative 006E543B07256EAF_= Content-Type: text/plain; charset="US-ASCII" Here it is. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --=_alternative 006E543B07256EAF_= Content-Type: text/html; charset="US-ASCII"
Here it is.



Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX:      (503) 578-3228 --=_alternative 006E543B07256EAF_=-- --=_mixed 006E543B07256EAF_= Content-Type: application/octet-stream; name="linux-2.6.7-rc3.dst.patch" Content-Disposition: attachment; filename="linux-2.6.7-rc3.dst.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdXJOIGxpbnV4LTIuNi43LXJjMy9uZXQvaXB2Ni9uZGlzYy5jIGxpbnV4LTIuNi43LXJj My5kc3QvbmV0L2lwdjYvbmRpc2MuYwotLS0gbGludXgtMi42LjctcmMzL25ldC9pcHY2L25kaXNj LmMJMjAwNC0wNi0wOSAxNjo0Mjo1NS4wMDAwMDAwMDAgLTA3MDAKKysrIGxpbnV4LTIuNi43LXJj My5kc3QvbmV0L2lwdjYvbmRpc2MuYwkyMDA0LTA2LTEwIDEyOjUxOjM5LjAwMDAwMDAwMCAtMDcw MApAQCAtMzk1LDcgKzM5NSw3IEBACiAKIAluZGlzY19mbG93X2luaXQoJmZsLCBORElTQ19ORUlH SEJPVVJfQURWRVJUSVNFTUVOVCwgc3JjX2FkZHIsIGRhZGRyKTsKIAotCWRzdCA9IG5kaXNjX2Rz dF9hbGxvYyhkZXYsIG5laWdoLCBkYWRkciwgaXA2X291dHB1dDIpOworCWRzdCA9IG5kaXNjX2Rz dF9hbGxvYyhkZXYsIG5laWdoLCBkYWRkciwgaXA2X291dHB1dCk7CiAJaWYgKCFkc3QpCiAJCXJl dHVybjsKIApAQCAtNDg2LDcgKzQ4Niw3IEBACiAKIAluZGlzY19mbG93X2luaXQoJmZsLCBORElT Q19ORUlHSEJPVVJfU09MSUNJVEFUSU9OLCBzYWRkciwgZGFkZHIpOwogCi0JZHN0ID0gbmRpc2Nf ZHN0X2FsbG9jKGRldiwgbmVpZ2gsIGRhZGRyLCBpcDZfb3V0cHV0Mik7CisJZHN0ID0gbmRpc2Nf ZHN0X2FsbG9jKGRldiwgbmVpZ2gsIGRhZGRyLCBpcDZfb3V0cHV0KTsKIAlpZiAoIWRzdCkKIAkJ cmV0dXJuOwogCkBAIC01NjIsNyArNTYyLDcgQEAKIAogCW5kaXNjX2Zsb3dfaW5pdCgmZmwsIE5E SVNDX1JPVVRFUl9TT0xJQ0lUQVRJT04sIHNhZGRyLCBkYWRkcik7CiAKLQlkc3QgPSBuZGlzY19k c3RfYWxsb2MoZGV2LCBOVUxMLCBkYWRkciwgaXA2X291dHB1dDIpOworCWRzdCA9IG5kaXNjX2Rz dF9hbGxvYyhkZXYsIE5VTEwsIGRhZGRyLCBpcDZfb3V0cHV0KTsKIAlpZiAoIWRzdCkKIAkJcmV0 dXJuOwogCmRpZmYgLXVyTiBsaW51eC0yLjYuNy1yYzMvbmV0L2lwdjYvcm91dGUuYyBsaW51eC0y LjYuNy1yYzMuZHN0L25ldC9pcHY2L3JvdXRlLmMKLS0tIGxpbnV4LTIuNi43LXJjMy9uZXQvaXB2 Ni9yb3V0ZS5jCTIwMDQtMDYtMDkgMTY6NDI6NTUuMDAwMDAwMDAwIC0wNzAwCisrKyBsaW51eC0y LjYuNy1yYzMuZHN0L25ldC9pcHY2L3JvdXRlLmMJMjAwNC0wNi0xMCAxMjo1MzozMC4wMDAwMDAw MDAgLTA3MDAKQEAgLTU3Myw2ICs1NzMsOCBAQAogCiAvKiBQcm90ZWN0ZWQgYnkgcnQ2X2xvY2su ICAqLwogc3RhdGljIHN0cnVjdCBkc3RfZW50cnkgKm5kaXNjX2RzdF9nY19saXN0Oworc3RhdGlj IGludCBpcHY2X2dldF9tdHUoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7CitzdGF0aWMgaW5saW5l IHVuc2lnbmVkIGludCBpcHY2X2Fkdm1zcyh1bnNpZ25lZCBpbnQgbXR1KTsKIAogc3RydWN0IGRz dF9lbnRyeSAqbmRpc2NfZHN0X2FsbG9jKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIAogCQkJCSAg c3RydWN0IG5laWdoYm91ciAqbmVpZ2gsCkBAIC01OTgsNiArNjAwLDggQEAKIAlydC0+cnQ2aV9t ZXRyaWMgICA9IDA7CiAJYXRvbWljX3NldCgmcnQtPnUuZHN0Ll9fcmVmY250LCAxKTsKIAlydC0+ dS5kc3QubWV0cmljc1tSVEFYX0hPUExJTUlULTFdID0gMjU1OworCXJ0LT51LmRzdC5tZXRyaWNz W1JUQVhfTVRVLTFdID0gaXB2Nl9nZXRfbXR1KHJ0LT5ydDZpX2Rldik7CisJcnQtPnUuZHN0Lm1l dHJpY3NbUlRBWF9BRFZNU1MtMV0gPSBpcHY2X2Fkdm1zcyhkc3RfcG10dSgmcnQtPnUuZHN0KSk7 CiAJcnQtPnUuZHN0Lm91dHB1dCAgPSBvdXRwdXQ7CiAKIAl3cml0ZV9sb2NrX2JoKCZydDZfbG9j ayk7Cg== --=_mixed 006E543B07256EAF_=-- From felipe_alfaro@linuxmail.org Thu Jun 10 13:08:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 13:08:56 -0700 (PDT) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AK8ngi027191 for ; Thu, 10 Jun 2004 13:08:49 -0700 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id B2D9842D1B; Thu, 10 Jun 2004 22:08:39 +0200 (CEST) Subject: Re: 2.6.7-rc3: waiting for eth0 to become free From: Felipe Alfaro Solana To: Stephen Hemminger Cc: NetDev Mailinglist , Kernel Mailinglist In-Reply-To: <20040610083652.6f3ba3a6@dell_ss3.pdx.osdl.net> References: <1086722310.1682.1.camel@teapot.felipe-alfaro.com> <20040608124215.291a7072@dell_ss3.pdx.osdl.net> <1086725369.1806.1.camel@teapot.felipe-alfaro.com> <20040608140200.2ddaa6f4@dell_ss3.pdx.osdl.net> <1086794282.1706.2.camel@teapot.felipe-alfaro.com> <20040610083652.6f3ba3a6@dell_ss3.pdx.osdl.net> Content-Type: multipart/mixed; boundary="=-RnxxLieq1EmsPewn9/I0" Date: Thu, 10 Jun 2004 22:08:46 +0200 Message-Id: <1086898126.2542.0.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 (1.5.9.1-2) X-archive-position: 5841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: netdev Content-Length: 6531 Lines: 182 --=-RnxxLieq1EmsPewn9/I0 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2004-06-10 at 08:36 -0700, Stephen Hemminger wrote: > On Wed, 09 Jun 2004 17:18:02 +0200 > Felipe Alfaro Solana wrote: > > > On Tue, 2004-06-08 at 14:02 -0700, Stephen Hemminger wrote: > > > On Tue, 08 Jun 2004 22:09:29 +0200 > > > Felipe Alfaro Solana wrote: > > > > > > > On Tue, 2004-06-08 at 12:42 -0700, Stephen Hemminger wrote: > > > > > On Tue, 08 Jun 2004 21:18:30 +0200 > > > > > Felipe Alfaro Solana wrote: > > > > > > > > > > > Hi! > > > > > > > > > > > > On my laptop, when using a CardBus 3c59x-based NIC, I need to run > > > > > > "cardctl eject" so the system won't freeze when resuming. "cardctl > > > > > > eject" worked fine in 2.6.7-rc2-mm2, even when there were programs with > > > > > > network sockets opened (for example, Evolution mantaining a connection > > > > > > against an IMAP server): the card is ejected (well, not physically), > > > > > > even when there are ESTABLISHED connections. > > > > > > > > > > > > However, starting with 2.6.7-rc3, "cardctl eject" hangs if a program > > > > > > holds any socket open. After a while the "unregister_netdevice: waiting > > > > > > for eth0 to become free" message starts appearing on the kernel message > > > > > > ring. The only apparent solution is killing that program, ejecting the > > > > > > card from its slot and wait until 3c59x.o usage count reaches zero. > > > > > > > > > > > > Can someone tell me what's going on here? > > > > > > Thank you very much. > > > > > > > > > > What protocols are you running? Is IPV6 loaded? > > > > > > > > I'm using IPv4, IPv6 and IPSec ESP with AES/CBC. > > > > Do you want .config? > > > > > > Not really, could you see if it is an IPv6 vs IPSec problem by not running/loading > > > one or the other. > > > > > > What is happening is that some subsystem is holding a reference to the device (calling dev_hold()) > > > but not cleaning up (calling dev_put). It can be a hard to track which of the many > > > things routing, etc are not being cleared properly. Look for routes that still > > > get stuck (ip route) and neighbor cache entries. Most of these end up being > > > protocol bugs. > > > > The two attached patches, one for net/ipv4/route.c, the other for net/ > > ipv6/route.c fix all my problems when running "cardctl eject" while a > > program mantains an open network socket (ESTABLISHED). > > > > Both patches apply cleanly against 2.6.7-rc3 and 2.6.7-rc3-mm1. > > I'm not completely sure what has changed in 2.6.7-rc3 that is breaking > > cardctl for me, as it Just Worked(TM) fine in 2.6.7-rc2. > > > > Hope this can throw some light at this issue. > > Since you effectively remove rth->idev, why not remove it from the structure > to make sure no code is still expecting it to be set. What about the following one? Tested on 2.6.7-rc3-mm1. --=-RnxxLieq1EmsPewn9/I0 Content-Disposition: attachment; filename=ip-route-fix-refcount.patch Content-Type: text/x-patch; name=ip-route-fix-refcount.patch; charset=utf-8 Content-Transfer-Encoding: 7bit diff -uNr linux-2.6.7-rc3-mm1.old/include/net/route.h linux-2.6.7-rc3-mm1/include/net/route.h --- linux-2.6.7-rc3-mm1.old/include/net/route.h 2004-06-10 21:22:15.877298171 +0200 +++ linux-2.6.7-rc3-mm1/include/net/route.h 2004-06-10 21:09:34.000000000 +0200 @@ -55,8 +55,6 @@ struct rtable *rt_next; } u; - struct in_device *idev; - unsigned rt_flags; unsigned rt_type; diff -uNr linux-2.6.7-rc3-mm1.old/net/ipv4/route.c linux-2.6.7-rc3-mm1/net/ipv4/route.c --- linux-2.6.7-rc3-mm1.old/net/ipv4/route.c 2004-06-10 21:22:16.042259029 +0200 +++ linux-2.6.7-rc3-mm1/net/ipv4/route.c 2004-06-10 21:18:14.280624151 +0200 @@ -1040,8 +1040,6 @@ rt->u.dst.child = NULL; if (rt->u.dst.dev) dev_hold(rt->u.dst.dev); - if (rt->idev) - in_dev_hold(rt->idev); rt->u.dst.obsolete = 0; rt->u.dst.lastuse = jiffies; rt->u.dst.path = &rt->u.dst; @@ -1323,17 +1321,11 @@ { struct rtable *rt = (struct rtable *) dst; struct inet_peer *peer = rt->peer; - struct in_device *idev = rt->idev; if (peer) { rt->peer = NULL; inet_putpeer(peer); } - - if (idev) { - rt->idev = NULL; - in_dev_put(idev); - } } static void ipv4_link_failure(struct sk_buff *skb) @@ -1496,7 +1488,6 @@ rth->fl.iif = dev->ifindex; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); rth->fl.oif = 0; rth->rt_gateway = daddr; rth->rt_spec_dst= spec_dst; @@ -1706,7 +1697,6 @@ 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; @@ -1786,7 +1776,6 @@ rth->fl.iif = dev->ifindex; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); rth->rt_gateway = daddr; rth->rt_spec_dst= spec_dst; rth->u.dst.input= ip_local_deliver; @@ -2170,7 +2159,6 @@ 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; diff -uNr linux-2.6.7-rc3-mm1.old/net/ipv6/route.c linux-2.6.7-rc3-mm1/net/ipv6/route.c --- linux-2.6.7-rc3-mm1.old/net/ipv6/route.c 2004-06-10 21:22:16.068252861 +0200 +++ linux-2.6.7-rc3-mm1/net/ipv6/route.c 2004-06-10 00:07:10.000000000 +0200 @@ -584,14 +584,14 @@ if (unlikely(rt == NULL)) goto out; - dev_hold(dev); + if(dev) + dev_hold(dev); if (neigh) neigh_hold(neigh); else neigh = ndisc_get_neigh(dev, addr); rt->rt6i_dev = dev; - rt->rt6i_idev = in6_dev_get(dev); rt->rt6i_nexthop = neigh; rt->rt6i_expires = 0; rt->rt6i_flags = RTF_LOCAL; @@ -882,7 +882,6 @@ if (!rt->u.dst.metrics[RTAX_ADVMSS-1]) rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.dev = dev; - rt->rt6i_idev = in6_dev_get(dev); return rt6_ins(rt, nlh, _rtattr); out: @@ -1301,7 +1300,6 @@ rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; - rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); --=-RnxxLieq1EmsPewn9/I0-- From pp@ee.oulu.fi Thu Jun 10 13:34:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 13:34:49 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AKYigi027959 for ; Thu, 10 Jun 2004 13:34:45 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.11/8.12.11) with ESMTP id i5AKYgWf027933; Thu, 10 Jun 2004 23:34:42 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i5AKYgQE027899; Thu, 10 Jun 2004 23:34:42 +0300 (EEST) Date: Thu, 10 Jun 2004 23:34:42 +0300 From: Pekka Pietikainen To: Pavel Machek Cc: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040610203442.GA27762@ee.oulu.fi> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> <20040605131923.232f8950.davem@redhat.com> <20040609122905.GA12715@ee.oulu.fi> <20040610200504.GG4507@openzaurus.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20040610200504.GG4507@openzaurus.ucw.cz> User-Agent: Mutt/1.4.2i X-archive-position: 5842 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: 867 Lines: 20 On Thu, Jun 10, 2004 at 10:05:04PM +0200, Pavel Machek wrote: > This should hit machines with 2GB ram too, right? > Is it possible to find if it hits me? I get hard lockups on > 2GB machine with b44, but they take ~5min.. few hours to > reproduce... > > It seems to me like this should hit very quickly. > -- > 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms > Yikes! With the 4:4 VM split it definately is instantaneous with > 1GB of memory, I triggered it with 1.25G myself and never noticed anything wrong with just 1GB (allocation starts from the top it seems). With the standard 1:3 split I don't think anything > 1GB ever gets used for skbuffs, but maybe there are circumstances where this can happen? (Or the issue isn't fully understood yet, figuring out what breaks and what doesn't was basically just trial and error :-/ ) From pavel@atrey.karlin.mff.cuni.cz Thu Jun 10 13:44:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 13:44:38 -0700 (PDT) Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AKiMgi028428 for ; Thu, 10 Jun 2004 13:44:23 -0700 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 2596F4B43A8; Thu, 10 Jun 2004 22:09:28 +0200 (CEST) Date: Thu, 10 Jun 2004 22:05:04 +0200 From: Pavel Machek To: Pekka Pietikainen Cc: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040610200504.GG4507@openzaurus.ucw.cz> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> <20040605131923.232f8950.davem@redhat.com> <20040609122905.GA12715@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040609122905.GA12715@ee.oulu.fi> User-Agent: Mutt/1.3.27i X-archive-position: 5843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: netdev Content-Length: 665 Lines: 21 Hi! > > > + if(virt_to_bus(skb->data) + skb->len > B44_PCI_DMA_MAX) { > > > > You can't use this non-portable interface, you have to: > > > > 1) pci_map the data > > 2) test the dma_addr_t returned > Ok, fixed. Certainly not ideal, but should fix things for those with > problems (ie. running the 4G4G patch) and work as before for everyone else. > This should hit machines with 2GB ram too, right? Is it possible to find if it hits me? I get hard lockups on 2GB machine with b44, but they take ~5min.. few hours to reproduce... It seems to me like this should hit very quickly. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms From xma@us.ibm.com Thu Jun 10 13:46:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 13:46:50 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AKkYgk028795 for ; Thu, 10 Jun 2004 13:46:43 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5AKkSwc493632; Thu, 10 Jun 2004 16:46:28 -0400 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5AKkJ0A154594; Thu, 10 Jun 2004 14:46:23 -0600 In-Reply-To: To: Shirley Ma Cc: davem@redhat.com, mashirle@us.ibm.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= MIME-Version: 1.0 Subject: Re: [PATCH] dst allocation problem in ndisc X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Shirley Ma Date: Thu, 10 Jun 2004 14:46:20 -0600 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/10/2004 14:46:22 Content-Type: multipart/mixed; boundary="=_mixed 00720E5F07256EAF_=" X-archive-position: 5844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4764 Lines: 91 --=_mixed 00720E5F07256EAF_= Content-Type: multipart/alternative; boundary="=_alternative 00720E5F07256EAF_=" --=_alternative 00720E5F07256EAF_= Content-Type: text/plain; charset="US-ASCII" Change ip6_output2 to static also. This patch is against 2.6.7-rc3. Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --=_alternative 00720E5F07256EAF_= Content-Type: text/html; charset="US-ASCII"
Change ip6_output2 to static also. This patch is against 2.6.7-rc3.



Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX:      (503) 578-3228

 --=_alternative 00720E5F07256EAF_=-- --=_mixed 00720E5F07256EAF_= Content-Type: application/octet-stream; name="linux-2.6.7-rc3.dst.patch" Content-Disposition: attachment; filename="linux-2.6.7-rc3.dst.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdXJOIGxpbnV4LTIuNi43LXJjMy9pbmNsdWRlL25ldC9pcHY2LmggbGludXgtMi42Ljct cmMzLmRzdC9pbmNsdWRlL25ldC9pcHY2LmgKLS0tIGxpbnV4LTIuNi43LXJjMy9pbmNsdWRlL25l dC9pcHY2LmgJMjAwNC0wNi0wOSAxNjo0Mjo0NS4wMDAwMDAwMDAgLTA3MDAKKysrIGxpbnV4LTIu Ni43LXJjMy5kc3QvaW5jbHVkZS9uZXQvaXB2Ni5oCTIwMDQtMDYtMTAgMTM6MzE6NDAuMDAwMDAw MDAwIC0wNzAwCkBAIC0zNTYsNyArMzU2LDYgQEAKICAqLwogCiBleHRlcm4gaW50CQkJaXA2X291 dHB1dChzdHJ1Y3Qgc2tfYnVmZiAqKnBza2IpOwotZXh0ZXJuIGludAkJCWlwNl9vdXRwdXQyKHN0 cnVjdCBza19idWZmICoqcHNrYik7CiBleHRlcm4gaW50CQkJaXA2X2ZvcndhcmQoc3RydWN0IHNr X2J1ZmYgKnNrYik7CiBleHRlcm4gaW50CQkJaXA2X2lucHV0KHN0cnVjdCBza19idWZmICpza2Ip OwogZXh0ZXJuIGludAkJCWlwNl9tY19pbnB1dChzdHJ1Y3Qgc2tfYnVmZiAqc2tiKTsKZGlmZiAt dXJOIGxpbnV4LTIuNi43LXJjMy9uZXQvaXB2Ni9pcDZfb3V0cHV0LmMgbGludXgtMi42LjctcmMz LmRzdC9uZXQvaXB2Ni9pcDZfb3V0cHV0LmMKLS0tIGxpbnV4LTIuNi43LXJjMy9uZXQvaXB2Ni9p cDZfb3V0cHV0LmMJMjAwNC0wNi0wOSAxNjo0Mjo1NS4wMDAwMDAwMDAgLTA3MDAKKysrIGxpbnV4 LTIuNi43LXJjMy5kc3QvbmV0L2lwdjYvaXA2X291dHB1dC5jCTIwMDQtMDYtMTAgMTM6MjU6MTUu MDAwMDAwMDAwIC0wNzAwCkBAIC0xMDcsNyArMTA3LDcgQEAKIH0KIAogCi1pbnQgaXA2X291dHB1 dDIoc3RydWN0IHNrX2J1ZmYgKipwc2tiKQorc3RhdGljIGludCBpcDZfb3V0cHV0MihzdHJ1Y3Qg c2tfYnVmZiAqKnBza2IpCiB7CiAJc3RydWN0IHNrX2J1ZmYgKnNrYiA9ICpwc2tiOwogCXN0cnVj dCBkc3RfZW50cnkgKmRzdCA9IHNrYi0+ZHN0OwpkaWZmIC11ck4gbGludXgtMi42LjctcmMzL25l dC9pcHY2L25kaXNjLmMgbGludXgtMi42LjctcmMzLmRzdC9uZXQvaXB2Ni9uZGlzYy5jCi0tLSBs aW51eC0yLjYuNy1yYzMvbmV0L2lwdjYvbmRpc2MuYwkyMDA0LTA2LTA5IDE2OjQyOjU1LjAwMDAw MDAwMCAtMDcwMAorKysgbGludXgtMi42LjctcmMzLmRzdC9uZXQvaXB2Ni9uZGlzYy5jCTIwMDQt MDYtMTAgMTI6NTE6MzkuMDAwMDAwMDAwIC0wNzAwCkBAIC0zOTUsNyArMzk1LDcgQEAKIAogCW5k aXNjX2Zsb3dfaW5pdCgmZmwsIE5ESVNDX05FSUdIQk9VUl9BRFZFUlRJU0VNRU5ULCBzcmNfYWRk ciwgZGFkZHIpOwogCi0JZHN0ID0gbmRpc2NfZHN0X2FsbG9jKGRldiwgbmVpZ2gsIGRhZGRyLCBp cDZfb3V0cHV0Mik7CisJZHN0ID0gbmRpc2NfZHN0X2FsbG9jKGRldiwgbmVpZ2gsIGRhZGRyLCBp cDZfb3V0cHV0KTsKIAlpZiAoIWRzdCkKIAkJcmV0dXJuOwogCkBAIC00ODYsNyArNDg2LDcgQEAK IAogCW5kaXNjX2Zsb3dfaW5pdCgmZmwsIE5ESVNDX05FSUdIQk9VUl9TT0xJQ0lUQVRJT04sIHNh ZGRyLCBkYWRkcik7CiAKLQlkc3QgPSBuZGlzY19kc3RfYWxsb2MoZGV2LCBuZWlnaCwgZGFkZHIs IGlwNl9vdXRwdXQyKTsKKwlkc3QgPSBuZGlzY19kc3RfYWxsb2MoZGV2LCBuZWlnaCwgZGFkZHIs IGlwNl9vdXRwdXQpOwogCWlmICghZHN0KQogCQlyZXR1cm47CiAKQEAgLTU2Miw3ICs1NjIsNyBA QAogCiAJbmRpc2NfZmxvd19pbml0KCZmbCwgTkRJU0NfUk9VVEVSX1NPTElDSVRBVElPTiwgc2Fk ZHIsIGRhZGRyKTsKIAotCWRzdCA9IG5kaXNjX2RzdF9hbGxvYyhkZXYsIE5VTEwsIGRhZGRyLCBp cDZfb3V0cHV0Mik7CisJZHN0ID0gbmRpc2NfZHN0X2FsbG9jKGRldiwgTlVMTCwgZGFkZHIsIGlw Nl9vdXRwdXQpOwogCWlmICghZHN0KQogCQlyZXR1cm47CiAKZGlmZiAtdXJOIGxpbnV4LTIuNi43 LXJjMy9uZXQvaXB2Ni9yb3V0ZS5jIGxpbnV4LTIuNi43LXJjMy5kc3QvbmV0L2lwdjYvcm91dGUu YwotLS0gbGludXgtMi42LjctcmMzL25ldC9pcHY2L3JvdXRlLmMJMjAwNC0wNi0wOSAxNjo0Mjo1 NS4wMDAwMDAwMDAgLTA3MDAKKysrIGxpbnV4LTIuNi43LXJjMy5kc3QvbmV0L2lwdjYvcm91dGUu YwkyMDA0LTA2LTEwIDEyOjUzOjMwLjAwMDAwMDAwMCAtMDcwMApAQCAtNTczLDYgKzU3Myw4IEBA CiAKIC8qIFByb3RlY3RlZCBieSBydDZfbG9jay4gICovCiBzdGF0aWMgc3RydWN0IGRzdF9lbnRy eSAqbmRpc2NfZHN0X2djX2xpc3Q7CitzdGF0aWMgaW50IGlwdjZfZ2V0X210dShzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2KTsKK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IGlwdjZfYWR2bXNzKHVu c2lnbmVkIGludCBtdHUpOwogCiBzdHJ1Y3QgZHN0X2VudHJ5ICpuZGlzY19kc3RfYWxsb2Moc3Ry dWN0IG5ldF9kZXZpY2UgKmRldiwgCiAJCQkJICBzdHJ1Y3QgbmVpZ2hib3VyICpuZWlnaCwKQEAg LTU5OCw2ICs2MDAsOCBAQAogCXJ0LT5ydDZpX21ldHJpYyAgID0gMDsKIAlhdG9taWNfc2V0KCZy dC0+dS5kc3QuX19yZWZjbnQsIDEpOwogCXJ0LT51LmRzdC5tZXRyaWNzW1JUQVhfSE9QTElNSVQt MV0gPSAyNTU7CisJcnQtPnUuZHN0Lm1ldHJpY3NbUlRBWF9NVFUtMV0gPSBpcHY2X2dldF9tdHUo cnQtPnJ0NmlfZGV2KTsKKwlydC0+dS5kc3QubWV0cmljc1tSVEFYX0FEVk1TUy0xXSA9IGlwdjZf YWR2bXNzKGRzdF9wbXR1KCZydC0+dS5kc3QpKTsKIAlydC0+dS5kc3Qub3V0cHV0ICA9IG91dHB1 dDsKIAogCXdyaXRlX2xvY2tfYmgoJnJ0Nl9sb2NrKTsK --=_mixed 00720E5F07256EAF_=-- From margitsw@t-online.de Thu Jun 10 13:59:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 13:59:46 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AKxggi029272 for ; Thu, 10 Jun 2004 13:59:43 -0700 Received: from fwd08.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1BYWdM-0004Ye-00; Thu, 10 Jun 2004 22:58:48 +0200 Received: from roglap.local (ZBt0HMZaQeS7E4iw4Zi9l6TdSxyPL-O5rAyFdyx7-Y+papp1jdgZEk@[217.224.17.202]) by fwd08.sul.t-online.com with esmtp id 1BYWdD-0YWSh60; Thu, 10 Jun 2004 22:58:39 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: Prism54 patches 9 and 14 never got to netdev Date: Thu, 10 Jun 2004 22:55:58 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200406102255.58179.margitsw@t-online.de> X-Seen: false X-ID: ZBt0HMZaQeS7E4iw4Zi9l6TdSxyPL-O5rAyFdyx7-Y+papp1jdgZEk X-archive-position: 5845 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: 137 Lines: 4 Resend of patches 9 and 14 never got through to netdev. Error on SMTP send to oss.sgi.com. Notification came back after 5 days ! Margit From pavel@ucw.cz Thu Jun 10 14:12:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 14:12:43 -0700 (PDT) Received: from amd.ucw.cz (postfix@gprs214-205.eurotel.cz [160.218.214.205]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ALCQgi029916 for ; Thu, 10 Jun 2004 14:12:30 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 466DE2BDBB; Thu, 10 Jun 2004 23:12:17 +0200 (CEST) Date: Thu, 10 Jun 2004 23:12:17 +0200 From: Pavel Machek To: Pekka Pietikainen Cc: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040610211217.GA6634@elf.ucw.cz> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> <20040605131923.232f8950.davem@redhat.com> <20040609122905.GA12715@ee.oulu.fi> <20040610200504.GG4507@openzaurus.ucw.cz> <20040610203442.GA27762@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610203442.GA27762@ee.oulu.fi> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 5846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 1210 Lines: 31 Hi! > > This should hit machines with 2GB ram too, right? > > Is it possible to find if it hits me? I get hard lockups on > > 2GB machine with b44, but they take ~5min.. few hours to > > reproduce... > > > > It seems to me like this should hit very quickly. > > -- > > 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms > > > Yikes! > > With the 4:4 VM split it definately is instantaneous with > 1GB of memory, I > triggered it with 1.25G myself and never noticed anything wrong with just > 1GB (allocation starts from the top it seems). With the standard 1:3 split I > don't think anything > 1GB ever gets used for skbuffs, but maybe there > are circumstances where this can happen? Okay, this is probably other problem. When the bug hit, what are the symptoms? > (Or the issue isn't fully understood yet, figuring out what breaks and what > doesn't was basically just trial and error :-/ ) Can you try the driver from broadcom? bcom4400, or how is it called. Its extremely ugly, but might get this kind of stuff right... Pavel -- People were complaining that M$ turns users into beta-testers... ...we turn them into developers, and they seem to like it that way! From dlstevens@us.ibm.com Thu Jun 10 15:47:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 15:47:51 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5AMlbgi031815 for ; Thu, 10 Jun 2004 15:47:44 -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.2) with ESMTP id i5AMlMY0639346; Thu, 10 Jun 2004 18:47:22 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5AMlL09208792; Thu, 10 Jun 2004 16:47:21 -0600 In-Reply-To: <1086874679.23004.17.camel@dillow.idleaire.com> To: Dave Dillow Cc: Andrew Morton , Jeff Garzik , Netdev , Roger Luethi MIME-Version: 1.0 Subject: Re: [0/3] mc_filter on big-endian arch X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 10 Jun 2004 15:47:19 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/10/2004 16:47:22, Serialize complete at 06/10/2004 16:47:22 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 5847 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: 599 Lines: 13 Roger suggested that I bring to "netdev" the comment I made to him in private e-mail about his FAQ, so here it is: if you add multicast addresses via "ip maddr" in the way described, it won't work for some hardware configurations. In particular, if you have an Ethernet switch that does IGMP snooping, the switch won't replicate multicast packets on ports that haven't had IGMP reports for the multicast address you're testing. In that case, having it in the hardware MAF doesn't help, and you'll need to do the IP-level join to get them delivered. +-DLS From jgarzik@pobox.com Thu Jun 10 16:33:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 16:33:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ANXZgi003842 for ; Thu, 10 Jun 2004 16:33:36 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BYZ38-0008Pp-4V; Fri, 11 Jun 2004 00:33:34 +0100 Message-ID: <40C8EFC1.9090205@pobox.com> Date: Thu, 10 Jun 2004 19:33:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Feldman CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 1/3] e100: stepping over err return code References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5848 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: 62 Lines: 2 applied all three patches, thanks and enjoy your sabbatical! From jgarzik@pobox.com Thu Jun 10 17:04:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 17:04: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.12.10/8.12.9) with SMTP id i5B04ngi005102 for ; Thu, 10 Jun 2004 17:04:50 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BYZXM-0000FS-Jp; Fri, 11 Jun 2004 01:04:48 +0100 Message-ID: <40C8F714.4090806@pobox.com> Date: Thu, 10 Jun 2004 20:04:36 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com Subject: Re: [PATCH 6/17 linux-2.6.7-rc2] prism54: Kernel compatibility (resend) References: <200406051448.08292.margitsw@t-online.de> In-Reply-To: <200406051448.08292.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5849 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: 93 Lines: 8 I believe I misread patch #6 before, it seems fine. Applied patches 6 through 17. Jeff From jgarzik@pobox.com Thu Jun 10 17:16:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 17:16:48 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B0GXgi005680 for ; Thu, 10 Jun 2004 17:16:34 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BYZii-0000qk-7L; Fri, 11 Jun 2004 01:16:32 +0100 Message-ID: <40C8F9D3.4020609@pobox.com> Date: Thu, 10 Jun 2004 20:16:19 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Feldman CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5850 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: 217 Lines: 10 applied to netdev-2.6 queue (and thus Andrew's -mm tree automatically). We'll let it stew in there for a while and get testing feedback. Your 3 recently-sent bugfixes will go straight upstream, of course. Jeff From jgarzik@pobox.com Thu Jun 10 17:52:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 17:52: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.12.10/8.12.9) with SMTP id i5B0qCgi006661 for ; Thu, 10 Jun 2004 17:52:13 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BYaHD-0001Br-F3; Fri, 11 Jun 2004 01:52:11 +0100 Message-ID: <40C9022F.8050102@pobox.com> Date: Thu, 10 Jun 2004 20:51:59 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] fix oops from acenic ethtool References: <20040604145333.34d1600f@dell_ss3.pdx.osdl.net> In-Reply-To: <20040604145333.34d1600f@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5851 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: 75 Lines: 2 applied to netdev-2.6 queue, and then removed the ifdefs I didn't like :) From anton@ozlabs.org Thu Jun 10 18:29:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 18:29:57 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B1Tqgi007789 for ; Thu, 10 Jun 2004 18:29:53 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 1A0012BD7B; Fri, 11 Jun 2004 11:29:47 +1000 (EST) Date: Fri, 11 Jun 2004 11:27:27 +1000 From: Anton Blanchard To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: Allow IP header alignment to be overriden Message-ID: <20040611012727.GA27672@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5852 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: 5949 Lines: 169 Hi, The networking layer currently aligns IP headers in rx packets. It does this via skb_reserve(,2). On some architectures (like ppc64) we handle most unaligned accesses in hardware. This means we gain little from this header alignment. However forcing this alignment means we attempt to DMA from an unaligned address. In the lab we see DMAs beginning at 2 bytes into the page. On some of our chips we have to do power of 2 writes of increasing size until we hit a reasonable alignment. It was noticeable on gigabit and now with 10Gbit appearing its becoming a real problem. Id be surprised if other architectures arent seeing similar issues, with bridges that disconnect at power of two boundaries. The following patch creates skb_align and allows an architecture to override it. Thoughts? Anton ===== drivers/net/acenic.c 1.44 vs edited ===== --- 1.44/drivers/net/acenic.c Tue Apr 6 18:01:26 2004 +++ edited/drivers/net/acenic.c Fri Jun 11 08:09:27 2004 @@ -1695,7 +1695,7 @@ /* * Make sure IP header starts on a fresh cache line. */ - skb_reserve(skb, 2 + 16); + skb_align(skb, 2 + 16); mapping = pci_map_page(ap->pdev, virt_to_page(skb->data), offset_in_page(skb->data), ACE_STD_BUFSIZE - (2 + 16), @@ -1761,7 +1761,7 @@ /* * Make sure the IP header ends up on a fresh cache line */ - skb_reserve(skb, 2 + 16); + skb_align(skb, 2 + 16); mapping = pci_map_page(ap->pdev, virt_to_page(skb->data), offset_in_page(skb->data), ACE_MINI_BUFSIZE - (2 + 16), @@ -1822,7 +1822,7 @@ /* * Make sure the IP header ends up on a fresh cache line */ - skb_reserve(skb, 2 + 16); + skb_align(skb, 2 + 16); mapping = pci_map_page(ap->pdev, virt_to_page(skb->data), offset_in_page(skb->data), ACE_JUMBO_BUFSIZE - (2 + 16), ===== drivers/net/e100.c 1.15 vs edited ===== --- 1.15/drivers/net/e100.c Sat Jun 5 01:49:59 2004 +++ edited/drivers/net/e100.c Fri Jun 11 08:00:49 2004 @@ -1395,7 +1395,7 @@ /* Align, init, and map the RFD. */ rx->skb->dev = nic->netdev; - skb_reserve(rx->skb, rx_offset); + skb_align(rx->skb, rx_offset); 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); ===== drivers/net/s2io.c 1.5 vs edited ===== --- 1.5/drivers/net/s2io.c Fri Jun 4 12:00:15 2004 +++ edited/drivers/net/s2io.c Fri Jun 11 08:06:52 2004 @@ -1431,7 +1431,7 @@ DBG_PRINT(ERR_DBG, "memory to allocate SKBs\n"); return -ENOMEM; } - skb_reserve(skb, HEADER_ALIGN_LAYER_3); + skb_align(skb, HEADER_ALIGN_LAYER_3); memset(rxdp, 0, sizeof(RxD_t)); rxdp->Buffer0_ptr = pci_map_single (nic->pdev, skb->data, size, PCI_DMA_FROMDEVICE); ===== drivers/net/tg3.c 1.180 vs edited ===== --- 1.180/drivers/net/tg3.c Sat Jun 5 01:49:59 2004 +++ edited/drivers/net/tg3.c Fri Jun 11 08:07:28 2004 @@ -2472,7 +2472,7 @@ goto drop_it_no_recycle; copy_skb->dev = tp->dev; - skb_reserve(copy_skb, 2); + skb_align(copy_skb, 2); skb_put(copy_skb, len); pci_dma_sync_single_for_cpu(tp->pdev, dma_addr, len, PCI_DMA_FROMDEVICE); memcpy(copy_skb->data, skb->data, len); ===== drivers/net/e1000/e1000_ethtool.c 1.45 vs edited ===== --- 1.45/drivers/net/e1000/e1000_ethtool.c Fri May 28 06:59:25 2004 +++ edited/drivers/net/e1000/e1000_ethtool.c Fri Jun 11 08:10:26 2004 @@ -1008,7 +1008,7 @@ ret_val = 6; goto err_nomem; } - skb_reserve(skb, 2); + skb_align(skb, 2); rxdr->buffer_info[i].skb = skb; rxdr->buffer_info[i].length = E1000_RXBUFFER_2048; rxdr->buffer_info[i].dma = ===== drivers/net/e1000/e1000_main.c 1.118 vs edited ===== --- 1.118/drivers/net/e1000/e1000_main.c Fri Jun 4 10:59:04 2004 +++ edited/drivers/net/e1000/e1000_main.c Fri Jun 11 08:05:39 2004 @@ -2387,7 +2387,7 @@ * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed */ - skb_reserve(skb, reserve_len); + skb_align(skb, reserve_len); skb->dev = netdev; ===== drivers/net/ixgb/ixgb_main.c 1.13 vs edited ===== --- 1.13/drivers/net/ixgb/ixgb_main.c Tue Jun 1 10:01:23 2004 +++ edited/drivers/net/ixgb/ixgb_main.c Fri Jun 11 08:41:13 2004 @@ -1906,7 +1906,7 @@ * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed */ - skb_reserve(skb, reserve_len); + skb_align(skb, reserve_len); skb->dev = netdev; ===== include/asm-ppc64/system.h 1.28 vs edited ===== --- 1.28/include/asm-ppc64/system.h Fri May 21 17:50:12 2004 +++ edited/include/asm-ppc64/system.h Fri Jun 11 08:39:11 2004 @@ -277,5 +277,15 @@ (unsigned long)_n_, sizeof(*(ptr))); \ }) +/* + * We handle most unaligned accesses in hardware. On the other hand + * unaligned DMA can be very expensive on some ppc64 IO chips (it does + * powers of 2 writes until it reaches sufficient alignment. + * + * Based on this we disable the IP header alignment in network drivers. + */ +#define ARCH_HAS_SKB_ALIGN +#define skb_align(SKB, LEN) do { } while (0) + #endif /* __KERNEL__ */ #endif ===== include/linux/skbuff.h 1.43 vs edited ===== --- 1.43/include/linux/skbuff.h Mon May 31 05:09:46 2004 +++ edited/include/linux/skbuff.h Fri Jun 11 08:27:42 2004 @@ -816,6 +816,20 @@ skb->tail += len; } +/** + * skb_align - align a buffer + * @skb: buffer to alter + * @len: bytes required to align + * + * Shift a buffer by len bytes for the purposes of alignment. On + * some architectures that handle unaligned accesses in hardware + * the effects of unaligned DMA is more costly so we allow it to + * be overridden. This is only allowed for an empty buffer. + */ +#ifndef ARCH_HAS_SKB_ALIGN +#define skb_align(SKB, LEN) skb_reserve((SKB), (LEN)) +#endif + extern int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc); static inline void __skb_trim(struct sk_buff *skb, unsigned int len) From anton@ozlabs.org Thu Jun 10 18:45:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 18:45:17 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B1jBgi008408 for ; Thu, 10 Jun 2004 18:45:12 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 299582BD7B; Fri, 11 Jun 2004 11:45:06 +1000 (EST) Date: Fri, 11 Jun 2004 11:43:55 +1000 From: Anton Blanchard To: Andi Kleen Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: Allow IP header alignment to be overriden Message-ID: <20040611014355.GB27672@krispykreme> References: <20040611012727.GA27672@krispykreme> <20040611013522.GA9809@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040611013522.GA9809@wotan.suse.de> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5853 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: 586 Lines: 22 > > +#ifndef ARCH_HAS_SKB_ALIGN > > +#define skb_align(SKB, LEN) skb_reserve((SKB), (LEN)) > > +#endif > > But where does this come from? There's no clear asm/ include in skbuff.h > matching it, and relying on indirect ones is probably not a good idea. Yeah I wasnt particularly happy about where I put the override. skbuff.h directly includes: #include #include ... #include system.h gets included way down in the file, so I picked system.h as the most reasonable of the three. Im open to ideas as to how to make this neater. Anton From herbert@gondor.apana.org.au Thu Jun 10 19:12:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 19:12:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B2CIgi009377 for ; Thu, 10 Jun 2004 19:12:19 -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 1BYbTb-0000lZ-00; Fri, 11 Jun 2004 12:09:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BYbTT-0001Qv-00; Fri, 11 Jun 2004 12:08:55 +1000 Date: Fri, 11 Jun 2004 12:08:55 +1000 To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: 4/x: [NETDRV] Merge register_netdev calls Message-ID: <20040611020855.GA5480@gondor.apana.org.au> References: <20040313025859.GA8186@gondor.apana.org.au> <405C294D.5040508@pobox.com> <20040520111937.GA21804@gondor.apana.org.au> <20040522074435.GA9628@gondor.apana.org.au> <20040529084109.GA13032@gondor.apana.org.au> <40BE3778.1020404@pobox.com> <20040605052737.GA27406@gondor.apana.org.au> <40C8F824.50904@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C8F824.50904@pobox.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5854 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: 1035 Lines: 28 On Thu, Jun 10, 2004 at 08:09:08PM -0400, Jeff Garzik wrote: > > Unfortunately this and patch #5 are moving in the opposition direction > from what we want to be doing, I think. > > AFAICS these patches move register_netdev() to points in each driver > earlier in the probe phase, when the driver is not fully set up and > ready to receive packets. > > Am I missing something? The only change made by these two patches is moving the call to register_netdev() from the outer probe() function to the inner probe() function where the the printk's are. There is absolutely no code in between the two locations. That is, the driver would've immediately called register_netdev after the inner probe() has succeeded. In fact it's really making these ISA/MCA probe() functions more like the ones we have for PCI. 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 Jun 10 19:24:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 19:24:39 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B2OOgi009810 for ; Thu, 10 Jun 2004 19: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 BF7806CC3A4; Fri, 11 Jun 2004 03:35:22 +0200 (CEST) Date: Fri, 11 Jun 2004 03:35:22 +0200 From: Andi Kleen To: Anton Blanchard Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: Allow IP header alignment to be overriden Message-ID: <20040611013522.GA9809@wotan.suse.de> References: <20040611012727.GA27672@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040611012727.GA27672@krispykreme> X-archive-position: 5855 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: 1001 Lines: 25 > The following patch creates skb_align and allows an architecture to > override it. Thoughts? I like it. While we haven't seen specific networking performance issues on Opteron yet it's certainly one architectures that doesn't care much about misalignment. The Intel EM64T CPUs have a bit more penalty, but also not much. It's certainly one optimization worth trying. > + * skb_align - align a buffer > + * @skb: buffer to alter > + * @len: bytes required to align > + * > + * Shift a buffer by len bytes for the purposes of alignment. On > + * some architectures that handle unaligned accesses in hardware > + * the effects of unaligned DMA is more costly so we allow it to > + * be overridden. This is only allowed for an empty buffer. > + */ > +#ifndef ARCH_HAS_SKB_ALIGN > +#define skb_align(SKB, LEN) skb_reserve((SKB), (LEN)) > +#endif But where does this come from? There's no clear asm/ include in skbuff.h matching it, and relying on indirect ones is probably not a good idea. -Andi From davem@redhat.com Thu Jun 10 21:58:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 21:58:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B4wTgi015992 for ; Thu, 10 Jun 2004 21:58: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 i5B4wPi5022253; Fri, 11 Jun 2004 00:58:25 -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 i5B4wP012660; Fri, 11 Jun 2004 00:58:25 -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 i5B4wB4X028404; Fri, 11 Jun 2004 00:58:11 -0400 Date: Thu, 10 Jun 2004 21:54:12 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] unclamp tcp receive window if doing dynamic receive sizing Message-Id: <20040610215412.09f0a457.davem@redhat.com> In-Reply-To: <20040607133056.5ab9e72d@dell_ss3.pdx.osdl.net> References: <20040607133056.5ab9e72d@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5856 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: 1849 Lines: 58 As a followup I've put the following into my tree after discussing some things with Stephen. He will do some of his tests to make sure this fixes things as it should. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/10 21:53:15-07:00 davem@nuts.davemloft.net # [TCP]: Receive buffer moderation fixes. # # 1) Make window clamp follow receive buffer growth so it # does not limit window advertisements. Noticed by John # Heffner and Stephen Hemminger. # 2) Fix rcvmem calculation such that tcp_adv_win_scale is # taken into account. # # net/ipv4/tcp_input.c # 2004/06/10 21:52:43-07:00 davem@nuts.davemloft.net +9 -1 # [TCP]: Receive buffer moderation fixes. # # 1) Make window clamp follow receive buffer growth so it # does not limit window advertisements. Noticed by John # Heffner and Stephen Hemminger. # # 2) Fix rcvmem calculation such that tcp_adv_win_scale is # taken into account. # diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-06-10 21:55:14 -07:00 +++ b/net/ipv4/tcp_input.c 2004-06-10 21:55:14 -07:00 @@ -463,6 +463,8 @@ tp->rcvq_space.space = space; if (sysctl_tcp_moderate_rcvbuf) { + int new_clamp = space; + /* Receive space grows, normalize in order to * take into account packet headers and sk_buff * structure overhead. @@ -472,10 +474,16 @@ space = 1; rcvmem = (tp->advmss + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff)); + while (tcp_win_from_space(rcvmem) < tp->advmss) + rcvmem += 128; space *= rcvmem; space = min(space, sysctl_tcp_rmem[2]); - if (space > sk->sk_rcvbuf) + if (space > sk->sk_rcvbuf) { sk->sk_rcvbuf = space; + + /* Make the window clamp follow along. */ + tp->window_clamp = new_clamp; + } } } From davem@redhat.com Thu Jun 10 22:12:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 22:12:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B5CJgi016683 for ; Thu, 10 Jun 2004 22:12:20 -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 i5B5CGi5024760; Fri, 11 Jun 2004 01:12:17 -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 i5B5CG014804; Fri, 11 Jun 2004 01:12: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 i5B5C2BY031471; Fri, 11 Jun 2004 01:12:02 -0400 Date: Thu, 10 Jun 2004 22:08:02 -0700 From: "David S. Miller" To: Shirley Ma Cc: xma@us.ibm.com, mashirle@us.ibm.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] dst allocation problem in ndisc Message-Id: <20040610220802.63e92631.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5857 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: 171 Lines: 6 On Thu, 10 Jun 2004 14:46:20 -0600 Shirley Ma wrote: > Change ip6_output2 to static also. This patch is against 2.6.7-rc3. Patch applied, thanks a lot! From davem@redhat.com Thu Jun 10 22:16:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 22:16:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B5G3gi017070 for ; Thu, 10 Jun 2004 22:16:05 -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 i5B5G1i5025357; Fri, 11 Jun 2004 01:16:01 -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 i5B5G1015285; Fri, 11 Jun 2004 01:16:01 -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 i5B5FlYP032272; Fri, 11 Jun 2004 01:15:47 -0400 Date: Thu, 10 Jun 2004 22:11:47 -0700 From: "David S. Miller" To: Shirley Ma Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, xma@us.ibm.com Subject: Re: [PATCH] some condition check error in ipsec v6 Message-Id: <20040610221147.2bef231d.davem@redhat.com> In-Reply-To: <200406091629.17365.mashirle@us.ibm.com> References: <200403311326.43647.mashirle@us.ibm.com> <200405261308.54281.mashirle@us.ibm.com> <200406091629.17365.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5858 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: 206 Lines: 7 On Wed, 9 Jun 2004 16:29:17 -0700 Shirley Ma wrote: > Here is a small patch for condition checking in ah6.c and esp6.c. This patch > is against 2.6.6 kernel. Applied, thanks a lot! From davem@redhat.com Thu Jun 10 22:40:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 22:40:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B5e4gi017655 for ; Thu, 10 Jun 2004 22:40:05 -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 i5B5e3i5029329; Fri, 11 Jun 2004 01:40: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 i5B5e3018695; Fri, 11 Jun 2004 01:40:03 -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 i5B5dnHk004335; Fri, 11 Jun 2004 01:39:50 -0400 Date: Thu, 10 Jun 2004 22:35:49 -0700 From: "David S. Miller" To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: Allow IP header alignment to be overriden Message-Id: <20040610223549.5e9ad025.davem@redhat.com> In-Reply-To: <20040611012727.GA27672@krispykreme> References: <20040611012727.GA27672@krispykreme> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5859 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: 526 Lines: 13 On Fri, 11 Jun 2004 11:27:27 +1000 Anton Blanchard wrote: > The following patch creates skb_align and allows an architecture to > override it. Thoughts? This transformation is not valid for a lot of drivers, that "2" in the reserve exists elsewhere in other calculations in the drivers. For example, it is added to the RX skb allocation size. Sometimes this '2' is there in non-trivial or hard to see ways (ie. it's implicitly in some DMA alignment value) That's the only reason I'm against this patch. From pp@ee.oulu.fi Thu Jun 10 23:17:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 23:17:36 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B6HWgi019007 for ; Thu, 10 Jun 2004 23:17:33 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.11/8.12.11) with ESMTP id i5B6HU25021264; Fri, 11 Jun 2004 09:17:30 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i5B6HUUl008430; Fri, 11 Jun 2004 09:17:30 +0300 (EEST) Date: Fri, 11 Jun 2004 09:17:30 +0300 From: Pekka Pietikainen To: Pavel Machek Cc: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040611061730.GA8081@ee.oulu.fi> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> <20040605131923.232f8950.davem@redhat.com> <20040609122905.GA12715@ee.oulu.fi> <20040610200504.GG4507@openzaurus.ucw.cz> <20040610203442.GA27762@ee.oulu.fi> <20040610211217.GA6634@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20040610211217.GA6634@elf.ucw.cz> User-Agent: Mutt/1.4.2i X-archive-position: 5860 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: 731 Lines: 13 On Thu, Jun 10, 2004 at 11:12:17PM +0200, Pavel Machek wrote: > Okay, this is probably other problem. When the bug hit, what are the symptoms? Total immediate crash without an oops. When the RX ring skbufs are allocated with GFP_DMA receives work, but any transmits from > 1GB cause a link down/link up (which is just about all of them). With GPF_DMA bounce buffers those start working too. > > (Or the issue isn't fully understood yet, figuring out what breaks and what > > doesn't was basically just trial and error :-/ ) > > Can you try the driver from broadcom? bcom4400, or how is it > called. Its extremely ugly, but might get this kind of stuff right... Tried that, it breaks with 4:4 and >1GB in exactly the same way :-) From mcgrof@studorgs.rutgers.edu Thu Jun 10 23:43:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jun 2004 23:43:24 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B6hAgi019695 for ; Thu, 10 Jun 2004 23:43:10 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 04296F98B1; Fri, 11 Jun 2004 02:43:09 -0400 (EDT) Date: Fri, 11 Jun 2004 02:43:09 -0400 To: Netdev Subject: [margitsw@t-online.de: Re: [PATCH 6/17 linux-2.6.7-rc2] prism54: Kernel compatibility (resend)] Message-ID: <20040611064309.GH24773@ruslug.rutgers.edu> Mail-Followup-To: Netdev Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 5861 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: 1403 Lines: 50 ----- Forwarded message from Margit Schubert-While ----- To: Jeff Garzik From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: [PATCH 6/17 linux-2.6.7-rc2] prism54: Kernel compatibility (resend) Cc: mcgrof@ruslug.rutgers.edu X-Seen: false X-ID: S8bLN4ZZQeIA8qC+ZpICD6L0IGei0K+D9QQxKNHm+ij+0kUy-mO-85 Hi Jeff, At 20:04 10.06.2004 -0400, you wrote: >I believe I misread patch #6 before, it seems fine. > >Applied patches 6 through 17. OK. Super. Thanks. Quick question - I have the next set of patches ready. These are not obtrusive - function definition cleanup (extraneous inlines, missing static) wmb() -> smp_wmb() dev_kfree_skb(_irq) -> dev_kfree_skb_any They depend on the previous patches 1 - 17. Should I wait until patches 1- 17 appear in kernel BK or can I start to send now ? Just for info - re. the question of -> #define init_wds 0 versus static const int init_wds = 0; I did some tests and it appears that gcc's < 3.3.3 don't optimize out the static const correctly. gcc 3.3.3 produces exactly the same code for both definitions. (ie. it optimizes it completely out) (Tested gcc versions 2.95, 3.2.1, 3.3.1, 3.3.3) Anyway, in the last patches, I left it as was ie. static const. Thanks again. Cheers Margit ----- End forwarded message ----- -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From sfeldma@pobox.com Fri Jun 11 00:39:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 00:39:22 -0700 (PDT) Received: from out007.verizon.net (out007pub.verizon.net [206.46.170.107]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B7dIgi024313 for ; Fri, 11 Jun 2004 00:39:19 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out007.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040611073918.MTFS28276.out007.verizon.net@[192.168.0.79]>; Fri, 11 Jun 2004 02:39:18 -0500 Subject: Re: Allow IP header alignment to be overriden From: Scott Feldman Reply-To: sfeldma@pobox.com To: "David S. Miller" Cc: Anton Blanchard , netdev@oss.sgi.com In-Reply-To: <20040610223549.5e9ad025.davem@redhat.com> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> Content-Type: text/plain Message-Id: <1086939562.3657.10.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 11 Jun 2004 00:39:22 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out007.verizon.net from [4.5.57.153] at Fri, 11 Jun 2004 02:39:17 -0500 X-archive-position: 5862 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: 445 Lines: 10 On Thu, 2004-06-10 at 22:35, David S. Miller wrote: > This transformation is not valid for a lot of drivers, that "2" > in the reserve exists elsewhere in other calculations in the > drivers. For example, it is added to the RX skb allocation > size. Sometimes this '2' is there in non-trivial or hard to > see ways (ie. it's implicitly in some DMA alignment value) Would replacing "2" with a macro that's defined on a per-arch basis work? From pavel@ucw.cz Fri Jun 11 02:45:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 02:45:43 -0700 (PDT) Received: from amd.ucw.cz (postfix@gprs214-150.eurotel.cz [160.218.214.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5B9jVgi030596 for ; Fri, 11 Jun 2004 02:45:36 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 0F5202BDBB; Fri, 11 Jun 2004 11:45:23 +0200 (CEST) Date: Fri, 11 Jun 2004 11:45:23 +0200 From: Pavel Machek To: Pekka Pietikainen Cc: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Dealing with buggy hardware (was: b44 and 4g4g) Message-ID: <20040611094523.GB13834@elf.ucw.cz> References: <20040531202104.GA8301@ee.oulu.fi> <20040605200643.GA2210@ee.oulu.fi> <20040605131923.232f8950.davem@redhat.com> <20040609122905.GA12715@ee.oulu.fi> <20040610200504.GG4507@openzaurus.ucw.cz> <20040610203442.GA27762@ee.oulu.fi> <20040610211217.GA6634@elf.ucw.cz> <20040611061730.GA8081@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040611061730.GA8081@ee.oulu.fi> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 5863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 945 Lines: 21 Hi! > > Okay, this is probably other problem. When the bug hit, what are the symptoms? > Total immediate crash without an oops. When the RX ring skbufs are allocated > with GFP_DMA receives work, but any transmits from > 1GB cause a link > down/link up (which is just about all of them). With GPF_DMA bounce > buffers those start working too. > > > > (Or the issue isn't fully understood yet, figuring out what breaks and what > > > doesn't was basically just trial and error :-/ ) > > > > Can you try the driver from broadcom? bcom4400, or how is it > > called. Its extremely ugly, but might get this kind of stuff right... > Tried that, it breaks with 4:4 and >1GB in exactly the same way :-) You might want to report them, then look at diff between latest and previous versions :-)))). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! From vda@port.imtp.ilyichevsk.odessa.ua Fri Jun 11 02:46:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 02:46:45 -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.12.10/8.12.9) with SMTP id i5B9bogi027522 for ; Fri, 11 Jun 2004 02:41:18 -0700 Received: (qmail 7829 invoked by alias); 11 Jun 2004 09:30:40 -0000 Received: from vda@port.imtp.ilyichevsk.odessa.ua by guard by uid 80 with qmail-scanner-1.22 ( Clear:RC:1(172.16.42.177):. Processed in 0.394616 secs); 11 Jun 2004 09:30:40 -0000 Received: from unknown (HELO firebird) (172.16.42.177) by 0 (172.16.22.3) with ESMTP; 11 Jun 2004 09:30:36 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Denis Vlasenko To: YOSHIFUJI Hideaki Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address Date: Fri, 11 Jun 2004 12:30:35 +0300 X-Mailer: KMail [version 1.4] Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, pekkas@netcore.fi, jmorris@redhat.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org References: <200406091425.39324.vda@port.imtp.ilyichevsk.odessa.ua> <20040609.212430.123946645.yoshfuji@linux-ipv6.org> In-Reply-To: <20040609.212430.123946645.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Message-Id: <200406111230.35481.vda@port.imtp.ilyichevsk.odessa.ua> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5B9bogi027522 X-archive-position: 5864 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: 2701 Lines: 92 On Wednesday 09 June 2004 15:24, YOSHIFUJI Hideaki wrote: > Denis Vlasenko says: > > I observe that UDP sockets listening on ANY > > send response packets with ip addr derived from > > ip address of interface which is used to send 'em > > instead of using dst ip address of client's packet. > > use IP_PKTINFO when responding the client. Thanks! With your help and some googling I've found and adapted code to get dst ip of UDP packet. Small test program successfully ran and reported correct dst addresses of incoming UDP packets. Now, I am trying to fix (or shall I say 'improve'?) dnscache. You may find some code below my sig. It's a start. The problem is, how to _send replies_ with correct src ip? I can bind a temporary socket to needed src address, do a sendto(), then close socket. This will work, but this can introduce a race - any incoming packet to this (ip,port) will inadvertently be classified as belonging to temp socket! This is going to be a nasty bug, manifesting itself only under load. I looked into sendmsg(). Looks like ther is no way to indicate source ip. Shall I use some other technique? -- vda #if defined IP_RECVDSTADDR # define DSTADDR_SOCKOPT IP_RECVDSTADDR # define DSTADDR_DATASIZE (CMSG_SPACE(sizeof(struct in_addr))) # define dstaddr(x) (CMSG_DATA(x)) #elif defined IP_PKTINFO # define DSTADDR_SOCKOPT IP_PKTINFO # define DSTADDR_DATASIZE (CMSG_SPACE(sizeof(struct in_pktinfo))) # define dstaddr(x) (&(((struct in_pktinfo *)(CMSG_DATA(x)))->ipi_addr)) #else # error "can't determine socket option" #endif int socket_recv4_dst(int s,char *buf,int len,char ip[4],uint16 *port, char ipdst[4]) { int r; struct iovec iov[1]; struct sockaddr_in sa; union control_data cmsg; struct cmsghdr *cmsgptr; struct msghdr msg; iov[0].iov_base = buf; iov[0].iov_len = len; memset(&msg, 0, sizeof msg); msg.msg_name = &sa; msg.msg_namelen = sizeof sa; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = &cmsg; msg.msg_controllen = sizeof cmsg; { // FIXME: we need to do it ONCE! move it into socket_bind4_dstaddropt() int sockopt; sockopt = 1; if (setsockopt(s, IPPROTO_IP, DSTADDR_SOCKOPT, &sockopt, sizeof sockopt) == -1) return -1; } //r = recvfrom(s,buf,len,0,(struct sockaddr *) &sa,&dummy); r = recvmsg(s, &msg, 0); if (r == -1) return -1; // Here we retrieve destination IP and memorize it for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL; cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) { if (cmsgptr->cmsg_level == IPPROTO_IP && cmsgptr->cmsg_type == DSTADDR_SOCKOPT) { byte_copy(ipdst,4,(char *) dstaddr(cmsgptr)); } } return r; } From herbert@gondor.apana.org.au Fri Jun 11 03:40:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 03:40:29 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BAeMgi002586 for ; Fri, 11 Jun 2004 03:40: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 1BYjMh-0003Sz-00; Fri, 11 Jun 2004 20:34:27 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BYjMY-0002CE-00; Fri, 11 Jun 2004 20:34:18 +1000 From: Herbert Xu To: vda@port.imtp.ilyichevsk.odessa.ua (Denis Vlasenko) Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, pekkas@netcore.fi, jmorris@redhat.com, linux-kernel@vger.kernel.org Organization: Core In-Reply-To: <200406111230.35481.vda@port.imtp.ilyichevsk.odessa.ua> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.net,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.25-1-686-smp (i686)) Message-Id: Date: Fri, 11 Jun 2004 20:34:18 +1000 X-archive-position: 5865 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: 484 Lines: 16 Denis Vlasenko wrote: > > I looked into sendmsg(). Looks like ther is no way to > indicate source ip. > > Shall I use some other technique? IP_PKTINFO works just as well there. Look at the ip_cmsg_send call in udp_sendmsg. 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 vkondra@mail.ru Fri Jun 11 04:02:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 04:02:54 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BB2mgi003480 for ; Fri, 11 Jun 2004 04:02:49 -0700 Received: from [81.218.179.11] (port=28037 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BYjnv-0007xO-00 for netdev@oss.sgi.com; Fri, 11 Jun 2004 15:02:37 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: TGe (QoS in wireless) Date: Fri, 11 Jun 2004 14:02:16 +0300 User-Agent: KMail/1.6.2 References: <200406090936.16943.vkondra@mail.ru> In-Reply-To: <200406090936.16943.vkondra@mail.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406111402.23898.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5BB2mgi003480 X-archive-position: 5866 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: 3191 Lines: 87 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 June 2004 09:36, Vladimir Kondratiev wrote: News: latest development in this group goes into direction, when "ACM" (Admission Control Mandatory) will be used for 2 high priority EDCA access categories (video and voice). This means, if STA want to Tx at high priority, it should request bandwidth from AP by creating TSPEC. If STA violete its spec, its traffic may be dropped by AP, or STA may be disconnected. Violations include: - - STA Tx packet at high priority without admission, - - STA exceed TSPEC's bandwidth This mean, unless we implement TGe in wireless, Linux STA will get lowest priority for its traffic. Vladimir. > I will give short overview for TGe. > > TGe is working group in IEEE, who is working on QoS for 802.11 wireless > network. This work is close to completion, final draft will be voted and > become standard shortly. > > Next generation of wireless cards will support TGe. > > Now, to the business. > > Single radio channel used. > > There are 2 access disciplines: > > - EDCA, which is CSCA, or contention based. 4 AC (access categories) exist, > they differ by channel access parameters. Parameters include backoff, > contention window and TXOP (more on this later). Parameters are set by AP > and may be changed during operation. > > - HCCA, which is contention free access. AP (access point) gives TXOP > directly to each STA, deciding who will speak. > > TXOP stands for transmitt opportunity. When each AC gets access to the > channel, it is allowed to do burst (without backoff) for TXOP period, which > is several ms. > > Traffic classified into 16 categories, or TID. Each packet get its TID. > TID 0-7 get mapped statically to 4 AC, roughly it corresponds to TOS bits. > > TID 8-15 mapped to TSPECs. TSPEC is traffic specification, which consist of > bandwidth specification (throughput, delay etc. - see RSVP for example) and > TCLAS - classifiers passed to AP side to classify packets. > > TSPEC may be for HCCA or EDCA access. In case of HCCA, it get simple > periodic schedule, set by AP. AP will poll STA accordingly to this > schedule, and Tx to STA accordingly to schedule. In case of EDCA, it is > just bandwidth allocation control. > > Admission. AP may enforce admission control for some (actually, 2 high > prio) AC, prohibiting its normal operation and requiring TSPEC > establishment in order to use these categories. > > I did not touched B-ACK (block ack), local broadcast, and DLP (direct link > protocol) that deals nothing with QoS. > > ----------below is my interpretation----------- > This leads to the following channel model : > - single Rx channel > - 4 FIFO/DMA rings, one per AC. > - 1 to 8 FIFO/DMA rings for TSPEC traffic. > In-NIC scheduler decides which FIFO get to the air. Time for decision is > about 10 us, thus it can't be done on host. > Decision is the following: > - poll from AP -> TSPEC > - channel is clear, random backoff expired -> AC > > Vladimir. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAyZE/qxdj7mhC6o0RAvhAAJ97+J8cMeW1ieFTU4WOMO0m3PlonACbBD2X Xf6n+chLDYWLJKuTWc0CTug= =3VtG -----END PGP SIGNATURE----- From hadi@cyberus.ca Fri Jun 11 05:18:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 05:18:32 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BCISgi014070 for ; Fri, 11 Jun 2004 05:18:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BYkzI-0001jl-S9 for netdev@oss.sgi.com; Fri, 11 Jun 2004 08:18:24 -0400 Received: from [24.103.99.32] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BYkzG-0007mY-4f; Fri, 11 Jun 2004 08:18:22 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, jt@hpl.hp.com In-Reply-To: <200406100855.37348.vkondra@mail.ru> References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406092127.28477.vkondra@mail.ru> <1086832740.1205.65.camel@jzny.localdomain> <200406100855.37348.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086956271.1065.651.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jun 2004 08:17:51 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5867 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: 1118 Lines: 32 On Thu, 2004-06-10 at 01:55, Vladimir Kondratiev wrote: > > Vladimir - do you have one of these cards? Jean is putting some my > > doubts in my mind about their designs. Do they have seperate DMA rings? > > Good question. Until I can really answer, let's say "in theory, all next > generation wireless cards should have similar design". Hint: I have also mail > ending by intel.com Ok, fine. > Sounds good. Next step is integrated service, where, prior to use some > priority, STA have to allocate bandwidth and get admission from AP. That part is easy using the current linux qdiscs - the hard part is getting the separate ids for each FIFO/DMA ring. > > > > Do you wanna try this? I could give you a hand but dont have much time > > to code at the moment. I could point you to the different pieces of code > > that need mods and suggest the changes. > > It would be great help. Please... > I promise to share results. Well, you are doing most of the work;-> Let me knwo when you have the NIC then we could start. Actually we could discuss even before you get the NIC; lets take it offline. cheers, jamal From vda@port.imtp.ilyichevsk.odessa.ua Fri Jun 11 05:49:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 05:49:39 -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.12.10/8.12.9) with SMTP id i5BCn6gi015392 for ; Fri, 11 Jun 2004 05:49:24 -0700 Received: (qmail 8590 invoked by alias); 11 Jun 2004 12:27:52 -0000 Received: from vda@port.imtp.ilyichevsk.odessa.ua by guard by uid 80 with qmail-scanner-1.22 ( Clear:RC:1(172.16.42.177):. Processed in 0.38995 secs); 11 Jun 2004 12:27:52 -0000 Received: from unknown (HELO firebird) (172.16.42.177) by 0 (172.16.22.3) with ESMTP; 11 Jun 2004 12:27:48 -0000 Content-Type: text/plain; charset="koi8-r" From: Denis Vlasenko To: Herbert Xu Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address Date: Fri, 11 Jun 2004 15:27:45 +0300 X-Mailer: KMail [version 1.4] Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, pekkas@netcore.fi, jmorris@redhat.com, linux-kernel@vger.kernel.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200406111527.45955.vda@port.imtp.ilyichevsk.odessa.ua> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5BCn6gi015392 X-archive-position: 5868 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: 1763 Lines: 59 On Friday 11 June 2004 13:34, Herbert Xu wrote: > Denis Vlasenko wrote: > > I looked into sendmsg(). Looks like ther is no way to > > indicate source ip. > > > > Shall I use some other technique? > > IP_PKTINFO works just as well there. Look at the ip_cmsg_send call > in udp_sendmsg. int udp_sendmsg(...) { ... ipc.addr = inet->saddr; ipc.oif = sk->sk_bound_dev_if; if (msg->msg_controllen) { err = ip_cmsg_send(msg, &ipc); if (err) return err; if (ipc.opt) free = 1; connected = 0; } if (!ipc.opt) ipc.opt = inet->opt; saddr = ipc.addr; ... int ip_cmsg_send(struct msghdr *msg, struct ipcm_cookie *ipc) { ... case IP_PKTINFO: { struct in_pktinfo *info; if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct in_pktinfo))) return -EINVAL; info = (struct in_pktinfo *)CMSG_DATA(cmsg); ipc->oif = info->ipi_ifindex; ipc->addr = info->ipi_spec_dst.s_addr; manpage: IP_PKTINFO Pass an IP_PKTINFO ancillary message that contains a pktinfo structure that supplies some information about the incoming packet. This only works for datagram oriented sockets. struct in_pktinfo { unsigned int ipi_ifindex; /* Interface index */ struct in_addr ipi_spec_dst; /* Routing destination address */ struct in_addr ipi_addr; /* Header Destination address */ }; Hmmm... do I have to set a *routing dest address* field to set src ip address of my UDP packet? -- vda From DanE@aiinet.com Fri Jun 11 06:01:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 06:01:08 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BD14gi015855 for ; Fri, 11 Jun 2004 06:01:04 -0700 Received: by AIMAIL1.ai.aiinet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jun 2004 09:01:20 -0400 Message-ID: From: "Eble, Dan" To: "'netdev@oss.sgi.com'" Subject: RFC: Cisco HDLC bridging Date: Fri, 11 Jun 2004 09:01:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 5869 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 Content-Length: 1173 Lines: 27 Greetings network geeks, I am about to implement Ethernet/802.3 over Cisco HDLC. My plan is to enhance hdlc_cisco.c to provide a new ethernet-like device, "cbeX" (cisco-bridged ethernet), corresponding to the existing "hdlcX" device that encapsulates the ethernet frames. The "cbeX" device will suddenly appear when "sethdlc hdlcX cisco ..." is run, and disappear when "hdlcX" is taken out of Cisco mode. Using a separate device for the bridged frames provides a way to get ethernet-like behavior without obscuring the Cisco nature of "hdlcX". For example, a tcpdump of "hdlcX" would still show SLARP keepalive frames and other ciscoey stuff. I had also considered simply making "hdlcX" look like an ethernet device, and "preserving" the SLARP packets for tcpdump by prepending a phony ethernet header. I abandoned that design because I could not find an appropriate ethertype to mark such packets. (It has other drawbacks too, but at least it would be simple.) Comments, suggestions, and warnings are welcome. -- Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| From hadi@cyberus.ca Fri Jun 11 06:14:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 06:14:52 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BDEmgi016558 for ; Fri, 11 Jun 2004 06:14:49 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BYlrp-0006TE-OY for netdev@oss.sgi.com; Fri, 11 Jun 2004 09:14:45 -0400 Received: from [24.103.99.32] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BYlrm-0007MQ-Nu for netdev@oss.sgi.com; Fri, 11 Jun 2004 09:14:42 -0400 Subject: this thing on? From: jamal Reply-To: hadi@cyberus.ca To: netdev@oss.sgi.com Content-Type: text/plain Organization: jamalopolis Message-Id: <1086959651.1065.678.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jun 2004 09:14:11 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5870 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: 54 Lines: 6 testing netdev - ignore message test1 cheers, jamal From ja@ssi.bg Fri Jun 11 06:53:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 06:53:49 -0700 (PDT) Received: from l.himel.bg (IDENT:root@[213.91.247.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BDrggi017849 for ; Fri, 11 Jun 2004 06:53:44 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.11.6/8.9.3) with ESMTP id i5BDrZc09743; Fri, 11 Jun 2004 16:53:35 +0300 Date: Fri, 11 Jun 2004 16:53:35 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: Denis Vlasenko cc: Herbert Xu , , , , , , , Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address In-Reply-To: <200406111527.45955.vda@port.imtp.ilyichevsk.odessa.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5871 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: 888 Lines: 47 Hello, On Fri, 11 Jun 2004, Denis Vlasenko wrote: > Hmmm... do I have to set a *routing dest address* field > to set src ip address of my UDP packet? Try such function: static int my_send(int fd, unsigned srcip, (struct sockaddr *) remote, char *data, int len) { struct iovec iov = { data, len }; struct { struct cmsghdr cm; struct in_pktinfo ipi; } cmsg = { .cm = { .cmsg_len = sizeof(struct cmsghdr) + sizeof(struct in_pktinfo), .cmsg_level = SOL_IP, .cmsg_type = IP_PKTINFO, }, .ipi = { .ipi_ifindex = 0, .ipi_spec_dst = srcip, }, }; struct msghdr m = { .msg_name = remote, .msg_namelen = sizeof(struct sockaddr_in), .msg_iov = &iov, .msg_iovlen = 1, .msg_control = &cmsg, .msg_controllen = sizeof(cmsg), .msg_flags = 0, }; return sendmsg(fd, &m, MSG_NOSIGNAL|MSG_DONTWAIT); } Regards -- Julian Anastasov From anton@ozlabs.org Fri Jun 11 07:12:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 07:13:05 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BECkgi018656 for ; Fri, 11 Jun 2004 07:12:47 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id EDFCC2BD3F; Sat, 12 Jun 2004 00:12:40 +1000 (EST) Date: Sat, 12 Jun 2004 00:08:43 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Allow IP header alignment to be overriden Message-ID: <20040611140843.GD27672@krispykreme> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610223549.5e9ad025.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5872 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: 812 Lines: 20 > This transformation is not valid for a lot of drivers, that "2" > in the reserve exists elsewhere in other calculations in the > drivers. For example, it is added to the RX skb allocation > size. Sometimes this '2' is there in non-trivial or hard to > see ways (ie. it's implicitly in some DMA alignment value) > > That's the only reason I'm against this patch. Yeah I started converting all drivers across to skb_align and quickly noticed that. We can instead convert drivers over as they are tested, the Gbit and 10Gbit cards being the most important. Ive tested the 2 10Gbit cards and one 1Gbit (e1000). I can test the acenic and should be able to hunt down a sungem and tg3. That leaves dl2K, myricom, ns83820, hamachi, yellowfin, r8169, and sk98lin which can be converted across as needed. Anton From anton@ozlabs.org Fri Jun 11 07:28:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 07:28:15 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BESBgi019202 for ; Fri, 11 Jun 2004 07:28:12 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id A03572BD85; Sat, 12 Jun 2004 00:28:05 +1000 (EST) Date: Sat, 12 Jun 2004 00:23:37 +1000 From: Anton Blanchard To: Scott Feldman Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Allow IP header alignment to be overriden Message-ID: <20040611142336.GE27672@krispykreme> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> <1086939562.3657.10.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086939562.3657.10.camel@sfeldma-mobl2.dsl-verizon.net> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5873 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: 844 Lines: 32 Hi, > Would replacing "2" with a macro that's defined on a per-arch basis > work? Nice idea. This would avoid us adding useless padding in that case, as we currently do: reserve_len = 2; skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); skb_reserve(skb, reserve_len); which would be nice if we are using a power of 2 buffer size. Would creating: /* * Network drivers want to align IP headers. Since we have 14 bytes of * ethernet header, adding 2 bytes will align the IP header. However * this will mean we do unaligned DMA so there is a trade off. * * We allow this to be overridden per arch as the unaligned DMA cost may * outweigh the unaligned CPU cost. */ #ifndef NET_IP_ALIGN #define NET_IP_ALIGN 2 #endif Instead of skb_align make more sense? It does have the advantage of removing another magic number. Anton From linux_lover2004@yahoo.com Fri Jun 11 08:46:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 08:46:46 -0700 (PDT) Received: from web52202.mail.yahoo.com (web52202.mail.yahoo.com [206.190.39.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BFkZgi028488 for ; Fri, 11 Jun 2004 08:46:36 -0700 Message-ID: <20040611154630.53576.qmail@web52202.mail.yahoo.com> Received: from [61.11.18.134] by web52202.mail.yahoo.com via HTTP; Fri, 11 Jun 2004 08:46:30 PDT Date: Fri, 11 Jun 2004 08:46:30 -0700 (PDT) From: linux lover Subject: confusion about socket buffers To: kernelnewbies Cc: netdev MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1962089936-1086968790=:51230" X-archive-position: 5874 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: 1030 Lines: 28 --0-1962089936-1086968790=:51230 Content-Type: text/plain; charset=us-ascii hello, i went through kernelnewbies mailing archive about socket buffer skbuff but not find satisfactory answer to my question? 1) what is difference between skb_push and skb_put? 2) does every skb_push require skb_reserve first? linux_lover. --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger --0-1962089936-1086968790=:51230 Content-Type: text/html; charset=us-ascii
hello,
     i went through kernelnewbies mailing archive
about socket buffer skbuff but not find satisfactory
answer to my question?

1) what is difference between skb_push and skb_put?
2) does every skb_push require skb_reserve first?
linux_lover.


 

Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger --0-1962089936-1086968790=:51230-- From scott.feldman@intel.com Fri Jun 11 11:50:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 11:50:19 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BIo5gi032292 for ; Fri, 11 Jun 2004 11:50: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 i5BInZjG019712; Fri, 11 Jun 2004 18:49:35 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5BIoxrE013824; Fri, 11 Jun 2004 18:51:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061111495601647 ; Fri, 11 Jun 2004 11:49:56 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jun 2004 11:49:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [RFC] Wireless extensions rethink Date: Fri, 11 Jun 2004 11:49:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] Wireless extensions rethink Thread-Index: AcRMyjmMeN60U1XlQeasCY0HbOH4rADE6p6w From: "Feldman, Scott" To: "Gertjan van Wingerde" Cc: X-OriginalArrivalTime: 11 Jun 2004 18:49:56.0767 (UTC) FILETIME=[E3E32AF0:01C44FE4] 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 i5BIo5gi032292 X-archive-position: 5875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 1042 Lines: 38 > I was thinking along the same lines, however I was taking the > ethtool interface as the starting point (using a single ioctl > for all wireless operations). The private handlers would just > have to be converted to plain ioctls handled by the driver itself. > > The attached patch can be used as a starting point for this. > It is not complete (not by far), but it shows the basic structure. > I've called the structure wlantool_ops, again using the > example set by ethtool. > > Comments? What if we just use the ethtool ioctl that's already defined, and extend ethtool with a wireless option: ethtool -w DEVNAME \ [ nwid N|off|on} ] \ [ freq x.xx ] \ [ mode ad-hoc|managed|master|repeater|... ] \ [ sens N ] \ [ ... ] Each one of the sub-options to -w would have it's own ETHTOOL_[G|S]W... command as well as a type-safe ethtool_op. Running ethtool DEVNAME dumps ETHTOOL_GW... : Wireless settings for eth0: nwid: AB34 freq: 2.422G mode: managed sens: -80 Good/bad idea? -scott From khc@pm.waw.pl Fri Jun 11 15:11:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 15:11:22 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BMBHgi006920 for ; Fri, 11 Jun 2004 15:11:18 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 4E570366; Sat, 12 Jun 2004 00:11:14 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 87037302D4; Fri, 11 Jun 2004 23:29:09 +0200 (CEST) To: "Eble, Dan" Cc: "'netdev@oss.sgi.com'" Subject: Re: RFC: Cisco HDLC bridging References: From: Krzysztof Halasa Date: Fri, 11 Jun 2004 23:29:08 +0200 In-Reply-To: (Dan Eble's message of "Fri, 11 Jun 2004 09:01:20 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5876 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 Content-Length: 1631 Lines: 40 "Eble, Dan" writes: > I am about to implement Ethernet/802.3 over Cisco HDLC. My plan is to > enhance hdlc_cisco.c to provide a new ethernet-like device, "cbeX" > (cisco-bridged ethernet), I would rather call it "hdlcXsomething", "cbeX" would not be very obvious to newcomers. And I would make it conditional (for example, with CONFIG_ option _and_ runtime ioctl creating the slave device). > corresponding to the existing "hdlcX" device that > encapsulates the ethernet frames. The "cbeX" device will suddenly appear > when "sethdlc hdlcX cisco ..." is run, and disappear when "hdlcX" is taken > out of Cisco mode. How are the packets encapsulated? What about 802.1q VLANs? > Using a separate device for the bridged frames provides a way to get > ethernet-like behavior without obscuring the Cisco nature of "hdlcX". For > example, a tcpdump of "hdlcX" would still show SLARP keepalive frames and > other ciscoey stuff. ... + Ethernet traffic with Cisco HDLC headers, that's it. However I don't feel like convinced to use the second network device. Certainly there is no problem with tcpdump/libpcap, we could have Cisco hdlcX device with SLARPs, Ethernet framing, regular IPv4/6 and anything we want. The only problem I can see (a serious one, though) is the protocol "routing" in Linux. If we "ip addr add" IP address to hdlcX, does it mean we want native IP or IP/Ethernet? It would be nice to be able to: ifconfig hdlc0 10.0.0.1/24 hw cisco-hdlc ifconfig hdlc0 10.0.1.1/24 hw ether at a time. The same applies to Frame Relay (we have pvcX and ethpvcX). -- Krzysztof Halasa, B*FH From jgarzik@pobox.com Fri Jun 11 16:28:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 16: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.12.10/8.12.9) with SMTP id i5BNSAgi011385 for ; Fri, 11 Jun 2004 16:28:11 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BYvRP-0005Dz-1d; Sat, 12 Jun 2004 00:28:07 +0100 Message-ID: <40CA3FF6.1020408@pobox.com> Date: Fri, 11 Jun 2004 19:27:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: netdev@oss.sgi.com, Nimrod Zimerman , Niibe Yutaka Subject: Re: [PATCH] Plip ioctl bug References: <20040611231154.GA21485@bougret.hpl.hp.com> In-Reply-To: <20040611231154.GA21485@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5877 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: 927 Lines: 32 Jean Tourrilhes wrote: > Hi all, > > Plip should verify that it got the proper ioctl to avoid false > positive. User reported that plip suddenly was gaining wireless > capability ;-) > Have fun... > > Jean > > Signed-off-by: $me > ------------------------------------------ > > diff -u -p linux/drivers/net/plip.b0.c linux/drivers/net/plip.c > --- linux/drivers/net/plip.b0.c Fri Jun 11 16:00:13 2004 > +++ linux/drivers/net/plip.c Fri Jun 11 16:03:14 2004 > @@ -1219,6 +1219,11 @@ plip_ioctl(struct net_device *dev, struc > struct net_local *nl = netdev_priv(dev); > struct plipconf *pc = (struct plipconf *) &rq->ifr_data; > > + /* Respond only to our IOCTL, ignore other IOCTLs, such as > + * Ethtool and Wireless Extensions. Jean II */ > + if(cmd != SIOCDEVPLIP) > + return -EOPNOTSUPP; > + > switch(pc->pcmd) { > case PLIP_GET_TIMEOUT: > pc->trigger = nl->trigger; already in the latest 2.6.x :) From jt@bougret.hpl.hp.com Fri Jun 11 16:45:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 16:45:10 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5BNipgi011908 for ; Fri, 11 Jun 2004 16:44:51 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id DE5283881E; Fri, 11 Jun 2004 16:11:55 -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 QAA02049; Fri, 11 Jun 2004 16:13:12 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BYvBi-0005hF-00; Fri, 11 Jun 2004 16:11:54 -0700 Date: Fri, 11 Jun 2004 16:11:54 -0700 To: netdev@oss.sgi.com, Jeff Garzik , Nimrod Zimerman , Niibe Yutaka Subject: [PATCH] Plip ioctl bug Message-ID: <20040611231154.GA21485@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: 5878 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: 816 Lines: 27 Hi all, Plip should verify that it got the proper ioctl to avoid false positive. User reported that plip suddenly was gaining wireless capability ;-) Have fun... Jean Signed-off-by: $me ------------------------------------------ diff -u -p linux/drivers/net/plip.b0.c linux/drivers/net/plip.c --- linux/drivers/net/plip.b0.c Fri Jun 11 16:00:13 2004 +++ linux/drivers/net/plip.c Fri Jun 11 16:03:14 2004 @@ -1219,6 +1219,11 @@ plip_ioctl(struct net_device *dev, struc struct net_local *nl = netdev_priv(dev); struct plipconf *pc = (struct plipconf *) &rq->ifr_data; + /* Respond only to our IOCTL, ignore other IOCTLs, such as + * Ethtool and Wireless Extensions. Jean II */ + if(cmd != SIOCDEVPLIP) + return -EOPNOTSUPP; + switch(pc->pcmd) { case PLIP_GET_TIMEOUT: pc->trigger = nl->trigger; From jt@bougret.hpl.hp.com Fri Jun 11 17:01:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 17:01:49 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5C01bgi012457 for ; Fri, 11 Jun 2004 17:01:37 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 1B7D2683C; Fri, 11 Jun 2004 16:40:18 -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 QAA02687; Fri, 11 Jun 2004 16:41:34 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BYvdB-0005vl-00; Fri, 11 Jun 2004 16:40:17 -0700 Date: Fri, 11 Jun 2004 16:40:17 -0700 To: Jeff Garzik Cc: netdev@oss.sgi.com, Nimrod Zimerman , Niibe Yutaka Subject: Re: [PATCH] Plip ioctl bug Message-ID: <20040611234017.GA22380@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040611231154.GA21485@bougret.hpl.hp.com> <40CA3FF6.1020408@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CA3FF6.1020408@pobox.com> 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: 5879 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: 236 Lines: 9 On Fri, Jun 11, 2004 at 07:27:50PM -0400, Jeff Garzik wrote: > > already in the latest 2.6.x :) Doh ! I'm still catching up with my e-mail (after familial events), I should have looked at the last kernel. Sorry about that... Jean From foner@media.mit.edu Fri Jun 11 19:48:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jun 2004 19:48:08 -0700 (PDT) Received: from out-of-band.media.mit.edu (out-of-band.media.mit.edu [18.85.16.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5C2lxgi015630 for ; Fri, 11 Jun 2004 19:48:00 -0700 Received: (from foner@localhost) by out-of-band.media.mit.edu (8.9.3/8.9.3/MEDIA) id WAA05324; Fri, 11 Jun 2004 22:47:36 -0400 (EDT) Date: Fri, 11 Jun 2004 22:47:36 -0400 (EDT) Message-Id: <200406120247.WAA05324@out-of-band.media.mit.edu> From: Lenny Foner To: c-d.hailfinger.kernel.2004@gmx.net CC: smolny@o2.pl, manfred@colorfullife.com, linux-kernel@vger.kernel.org, adq@lidskialf.net, netdev@oss.sgi.com, foner+x-forcedeth@media.mit.edu In-reply-to: <40C0863E.9070508@gmx.net> (message from Carl-Daniel Hailfinger on Fri, 04 Jun 2004 16:25:02 +0200) Subject: Forcedeth and vesa X-archive-position: 5880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: foner+x-forcedeth@media.mit.edu Precedence: bulk X-list: netdev Content-Length: 3519 Lines: 83 Date: Fri, 04 Jun 2004 16:25:02 +0200 From: Carl-Daniel Hailfinger [Note---if any discussion from the original message didn't CC me, I haven't seen it, because I'm not on these lists. If there has been, can someone clue me in? Tnx.] [Also, for those who may have seen the original messages from late May, I sent a long followup with many logfiles, but it wasn't delivered to anyone who was reading it on the mailing list, because it tripped the > 100K message limit on the lists. You can find it in http://foner.www.media.mit.edu/people/foner/Sys/forcedeth-stuff.txt if you'd like to see logfiles for working & nonworking cases. The subject line for the entire thread at that point was: forcedeth breaks X in Debian-testing 2.4.25 on MSI K7N2 Delta-L mobo] Hi, [foner: I included you in the CC because your problem seems similar.] It does. smolny@o2.pl wrote: > Hi, > Sorry if you get this post by mistake. I found your address googling > for "forcedeth vesa". Well, you reached the right person. > When i use forcedeth module, both with 2.4.26 and 2.6.6 kernels, i > can't access vesa with mplayer. Just loading the module doesn't > cause the problem, only after i configure the net with ifconfig i > can't use vesa. This is interesting. Does the problem persist if you ifdown the interface? In my case, the problem persists -forever- until reboot (I don't need to powercycle to fix it). It only happens once the interface gets used (e.g., if I just "insmod forcedeth", things are okay---but of course I don't have a network until I then do "ifdown eth0; ifup eth0", at which point X breaks the next time it's restarted, e.g., if I log out). However---when I first got your message a few days ago, while trying to figure out what made it break, I realized I was in a mode where I -did- have a network and could restart X successfully. Nothing I did made it break (un/reloading forcedeth, ifup/ifdown on the interface, etc). There was nothing out-of-the-ordinary about my session: I'd started it, did some light networking, and then left it alone for about a day and a half before I tried to debug. However, repeating this behavior after a reboot (over the last 2-3 days) hasn't managed to reproduce it ---instead, I'm back to the old behavior of X-broken-if-forcedeth-has handled-a-packet. (I -did- save a copy of the XF86 logfile from the working case, just in case anyone thinks it'd be enlightening, but wasn't sure what else I could possibly save that would be at all helpful.) So my guess is that there's some flakiness to this behavior, although I've only had the "working" situation once in thirty or more nonworking cases, so it's not -very- flaky. > If i use nvnet NVidia driver with 2.4.26, everything goes fine (no > nvnet for 2.6.x kernels). That is even more interesting. So the bug affects forcedeth, but not nvnet. Hmmm. We'll have to review the code again. [Note that I haven't tried this.] > It's an EPOX 8RDA+ motherboard. Foner: Do you see similarities between your problem and this one? Sure, given that he's complaining about VESA and that's why my X is dying. Janusz, Foner: Are you willing to test forcedeth with a few dozen iterations of patch, recompile, install, power down, power up and test again? I'm perfectly willing to do this. I would send you patches to binary search the offending code. Regards, Carl-Daniel From buytenh@wantstofly.org Sat Jun 12 05:51:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jun 2004 05:51:54 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5CCppgi018853 for ; Sat, 12 Jun 2004 05:51:51 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 9B1B32B0EC; Sat, 12 Jun 2004 14:51:49 +0200 (MEST) Date: Sat, 12 Jun 2004 14:51:49 +0200 From: Lennert Buytenhek To: netdev@oss.sgi.com Subject: arp(8) can create entry with with a broadcast/multicast MAC address Message-ID: <20040612125149.GA23367@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: 5881 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: 260 Lines: 16 (please CC on replies.) Hi, Just saw this: # /sbin/arp -s -i eth0 1.2.3.4 ff:ff:ff:ff:ff:ff # /sbin/arp -n | grep 1.2.3.4 1.2.3.4 ether FF:FF:FF:FF:FF:FF CM eth0 # Why does it allow me to do that? cheers, Lennert From hadi@cyberus.ca Sat Jun 12 11:02:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jun 2004 11:02:18 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5CI2Cgi002987 for ; Sat, 12 Jun 2004 11:02:13 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BYlLl-0006Zc-MA for netdev@oss.sgi.com; Fri, 11 Jun 2004 08:41:37 -0400 Received: from [24.103.99.32] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BYlLi-00022O-Hp; Fri, 11 Jun 2004 08:41:34 -0400 Subject: Re: Allow IP header alignment to be overriden From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Anton Blanchard , netdev@oss.sgi.com In-Reply-To: <20040610223549.5e9ad025.davem@redhat.com> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1086957663.1067.675.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jun 2004 08:41:03 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5882 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: 699 Lines: 22 On Fri, 2004-06-11 at 01:35, David S. Miller wrote: > On Fri, 11 Jun 2004 11:27:27 +1000 > Anton Blanchard wrote: > > > The following patch creates skb_align and allows an architecture to > > override it. Thoughts? > > This transformation is not valid for a lot of drivers, that "2" > in the reserve exists elsewhere in other calculations in the > drivers. For example, it is added to the RX skb allocation > size. Sometimes this '2' is there in non-trivial or hard to > see ways (ie. it's implicitly in some DMA alignment value) An interesting (annoying one) that falls into that category is sb1250-mac.c::sbdma_align_skb() shows up prominently in profiles cheers, jamal From davem@redhat.com Sat Jun 12 11:17:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jun 2004 11:17:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5CIH5gi003932 for ; Sat, 12 Jun 2004 11:17:06 -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 i5CIH5i5028460; Sat, 12 Jun 2004 14:17:05 -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 i5CIH4002946; Sat, 12 Jun 2004 14:17: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 i5CIGnpo008729; Sat, 12 Jun 2004 14:16:50 -0400 Date: Sat, 12 Jun 2004 11:12:18 -0700 From: "David S. Miller" To: Anton Blanchard Cc: sfeldma@pobox.com, netdev@oss.sgi.com Subject: Re: Allow IP header alignment to be overriden Message-Id: <20040612111218.783f587d.davem@redhat.com> In-Reply-To: <20040611142336.GE27672@krispykreme> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> <1086939562.3657.10.camel@sfeldma-mobl2.dsl-verizon.net> <20040611142336.GE27672@krispykreme> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5883 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: 895 Lines: 26 On Sat, 12 Jun 2004 00:23:37 +1000 Anton Blanchard wrote: > Would creating: > > /* > * Network drivers want to align IP headers. Since we have 14 bytes of > * ethernet header, adding 2 bytes will align the IP header. However > * this will mean we do unaligned DMA so there is a trade off. > * > * We allow this to be overridden per arch as the unaligned DMA cost may > * outweigh the unaligned CPU cost. > */ > #ifndef NET_IP_ALIGN > #define NET_IP_ALIGN 2 > #endif > > Instead of skb_align make more sense? It does have the advantage of > removing another magic number. Yes. Please add a paragraph to that comment explaining what "unaligned CPU cost" really means, ie. that the IP/TCP header members are going to be accessed with alignment less than the types might require on a given architecture. Then I'll apply this and we can start beating up the drivers. From vda@port.imtp.ilyichevsk.odessa.ua Sat Jun 12 15:15:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jun 2004 15:15:57 -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.12.10/8.12.9) with SMTP id i5CMFggi013459 for ; Sat, 12 Jun 2004 15:15:46 -0700 Received: (qmail 16387 invoked by alias); 12 Jun 2004 22:08:55 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 12 Jun 2004 22:08:55 -0000 From: Denis Vlasenko To: Julian Anastasov , Henrik Nordstrom Subject: Re: UDP sockets bound to ANY send answers with wrong src ip address Date: Sun, 13 Jun 2004 01:08:51 +0300 User-Agent: KMail/1.5.4 Cc: Herbert Xu , , , , , , , References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_z73yAPd94fdhgZl" Message-Id: <200406130108.51225.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 5884 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: 7872 Lines: 267 --Boundary-00=_z73yAPd94fdhgZl Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 11 June 2004 16:53, Julian Anastasov wrote: > Hello, > > On Fri, 11 Jun 2004, Denis Vlasenko wrote: > > Hmmm... do I have to set a *routing dest address* field > > to set src ip address of my UDP packet? > > Try such function: > > [snip] Thanks for your excellent help Julian. It helped me to finally make my code work. Pity I did not keep it that way, because it wouldn't be portable. I converted it to 'man cmsg' compliant way. On Friday 11 June 2004 17:14, Henrik Nordstrom wrote: > [snip] > > I am trying to figure it out, currently I'm getting > > -EINVAL in sendmsg in this code: > > > > # define SRCADDR_SOCKOPT IP_PKTINFO > > # define SRCADDR_DATASIZE (CMSG_SPACE(sizeof(struct in_pktinfo))) > > # define srcaddr(x) (&(((struct in_pktinfo > > *)(CMSG_DATA(x)))->ipi_spec_dst)) > > Drop the defines. These are only obfuscating your code and the source to > your error. You need to pass a in_pktinfo structure in the message, and They were there in the example recv code from the Net. That code tried to use IP_DSTADDR (IIRC) option (a BSDism or something) if it is #defined. Dropped #defines. I ended up with following patch for djbdns. Run tested. Thanks again for your help guys. -- vda --Boundary-00=_z73yAPd94fdhgZl Content-Type: text/x-diff; charset="windows-1251"; name="d.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="d.diff" diff -u djbdns-1.05.orig/dnscache.c djbdns-1.05.new/dnscache.c --- djbdns-1.05.orig/dnscache.c Sun Feb 11 23:11:45 2001 +++ djbdns-1.05.new/dnscache.c Sun Jun 13 00:51:52 2004 @@ -62,6 +62,7 @@ iopause_fd *io; char ip[4]; uint16 port; + char myip[4]; char id[2]; } u[MAXUDP]; int uactive = 0; @@ -78,7 +79,7 @@ if (!u[j].active) return; response_id(u[j].id); if (response_len > 512) response_tc(); - socket_send4(udp53,response,response_len,u[j].ip,u[j].port); + socket_send4_from(udp53,response,response_len,u[j].ip,u[j].port,u[j].myip); log_querydone(&u[j].active,response_len); u[j].active = 0; --uactive; } @@ -109,7 +110,7 @@ x = u + j; taia_now(&x->start); - len = socket_recv4(udp53,buf,sizeof buf,x->ip,&x->port); + len = socket_recv4_rememberdst(udp53,buf,sizeof buf,x->ip,&x->port,x->myip); if (len == -1) return; if (len >= sizeof buf) return; if (x->port < 1024) if (x->port != 53) return; diff -u djbdns-1.05.orig/socket.h djbdns-1.05.new/socket.h --- djbdns-1.05.orig/socket.h Sun Feb 11 23:11:45 2001 +++ djbdns-1.05.new/socket.h Sun Jun 13 00:51:44 2004 @@ -8,8 +8,8 @@ extern int socket_connect4(int,const char *,uint16); extern int socket_connected(int); -extern int socket_bind4(int,char *,uint16); -extern int socket_bind4_reuse(int,char *,uint16); +extern int socket_bind4(int,const char *,uint16); +extern int socket_bind4_reuse(int,const char *,uint16); extern int socket_listen(int,int); extern int socket_accept4(int,char *,uint16 *); extern int socket_recv4(int,char *,int,char *,uint16 *); @@ -18,5 +18,8 @@ extern int socket_remote4(int,char *,uint16 *); extern void socket_tryreservein(int,int); + +int socket_recv4_rememberdst(int s,char *buf,int len,char ip[4],uint16 *port, char ipdst[4]); +int socket_send4_from(int s,const char *buf,int len,const char ip[4],uint16 port,const char from[4]); #endif diff -u djbdns-1.05.orig/socket_bind.c djbdns-1.05.new/socket_bind.c --- djbdns-1.05.orig/socket_bind.c Sun Feb 11 23:11:45 2001 +++ djbdns-1.05.new/socket_bind.c Fri Jun 11 12:49:45 2004 @@ -5,7 +5,7 @@ #include "byte.h" #include "socket.h" -int socket_bind4(int s,char ip[4],uint16 port) +int socket_bind4(int s,const char ip[4],uint16 port) { struct sockaddr_in sa; @@ -17,7 +17,7 @@ return bind(s,(struct sockaddr *) &sa,sizeof sa); } -int socket_bind4_reuse(int s,char ip[4],uint16 port) +int socket_bind4_reuse(int s,const char ip[4],uint16 port) { int opt = 1; setsockopt(s,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof opt); diff -u djbdns-1.05.orig/socket_recv.c djbdns-1.05.new/socket_recv.c --- djbdns-1.05.orig/socket_recv.c Sun Feb 11 23:11:45 2001 +++ djbdns-1.05.new/socket_recv.c Sun Jun 13 00:51:48 2004 @@ -2,6 +2,7 @@ #include #include #include +#include /* memset() */ #include "byte.h" #include "socket.h" @@ -16,6 +17,57 @@ byte_copy(ip,4,(char *) &sa.sin_addr); uint16_unpack_big((char *) &sa.sin_port,port); + + return r; +} + +int socket_recv4_rememberdst(int s,char *buf,int len,char ip[4],uint16 *port, char ipdst[4]) +{ + int r; + + struct iovec iov[1]; + struct sockaddr_in remote; + char cmsg[CMSG_SPACE(sizeof(struct in_pktinfo))]; + struct cmsghdr *cmsgptr; + struct msghdr msg; + + iov[0].iov_base = buf; + iov[0].iov_len = len; + + memset(&msg, 0, sizeof(msg)); + msg.msg_name = &remote; + msg.msg_namelen = sizeof(remote); + msg.msg_iov = iov; + msg.msg_iovlen = 1; + msg.msg_control = &cmsg; + msg.msg_controllen = sizeof(cmsg); + + { // FIXME: do it only once + int sockopt; + sockopt = 1; + if (setsockopt(s, SOL_IP, IP_PKTINFO, &sockopt, sizeof sockopt) == -1) + return -1; + } + + r = recvmsg(s, &msg, 0); + if (r == -1) return -1; + + byte_copy(ip, 4, (char*)&remote.sin_addr); + uint16_unpack_big((char*)&remote.sin_port, port); + + /* Here we try to retrieve destination IP and memorize it */ + byte_copy(ipdst, 4, "\0\0\0" ); /* 4th '\0' char is also there */ + for (cmsgptr = CMSG_FIRSTHDR(&msg); + cmsgptr != NULL; + cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) { + if (cmsgptr->cmsg_level == SOL_IP + && cmsgptr->cmsg_type == IP_PKTINFO) { + +#define pktinfo(cmsgptr) ( (struct in_pktinfo*)(CMSG_DATA(cmsgptr)) ) + + byte_copy(ipdst, 4, (char*)(&pktinfo(cmsgptr)->ipi_addr) ); + } + } return r; } diff -u djbdns-1.05.orig/socket_send.c djbdns-1.05.new/socket_send.c --- djbdns-1.05.orig/socket_send.c Sun Feb 11 23:11:45 2001 +++ djbdns-1.05.new/socket_send.c Sun Jun 13 00:46:40 2004 @@ -2,6 +2,7 @@ #include #include #include +#include /* memset() */ #include "byte.h" #include "socket.h" @@ -15,4 +16,53 @@ byte_copy((char *) &sa.sin_addr,4,ip); return sendto(s,buf,len,0,(struct sockaddr *) &sa,sizeof sa); +} + +int socket_send4_from(int s,const char *buf,int len,const char ip[4],uint16 port,const char from[4]) +{ + /* man recvmsg and man cmsg is needed to make sense of code below */ + + struct sockaddr_in remote; + struct iovec iov[1]; + struct msghdr msg; + char cbuf[CMSG_SPACE(sizeof(struct in_pktinfo))]; + struct cmsghdr* cmsgptr; + struct in_pktinfo* pktptr; + + memset(&remote, 0, sizeof(remote)); + remote.sin_family = AF_INET; + uint16_pack_big( (char*)&remote.sin_port, port); + byte_copy( (char*)&remote.sin_addr, 4, ip); + + iov[0].iov_base = buf; + iov[0].iov_len = len; + + memset(cbuf, 0, sizeof(cbuf)); + + memset(&msg, 0, sizeof(msg)); + msg.msg_name = &remote; + msg.msg_namelen = sizeof(remote); + msg.msg_iov = iov; + msg.msg_iovlen = 1; + msg.msg_control = cbuf; + msg.msg_controllen = sizeof(cbuf); + + cmsgptr = CMSG_FIRSTHDR(&msg); + cmsgptr->cmsg_level = SOL_IP; + cmsgptr->cmsg_type = IP_PKTINFO; + cmsgptr->cmsg_len = CMSG_LEN(sizeof(struct in_pktinfo)); + +#define pktinfo(cmsgptr) ((struct in_pktinfo *)(CMSG_DATA(cmsgptr))) + + pktptr = pktinfo(cmsgptr); + /* pktptr->ipi_ifindex = 0; -- already done by memset(cbuf...) */ + byte_copy( (char*)(&pktptr->ipi_spec_dst), 4, from); + + { // FIXME: do it only once + int sockopt = 1; + if (setsockopt(s, SOL_IP, IP_PKTINFO, &sockopt, sizeof sockopt) == -1) + return -1; + } + + return sendmsg(s, &msg, 0); } --Boundary-00=_z73yAPd94fdhgZl-- From dave@thedillows.org Sat Jun 12 20:02:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jun 2004 20:02:05 -0700 (PDT) Received: from smtp1.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5D31xgi020507 for ; Sat, 12 Jun 2004 20:02:00 -0700 Received: (qmail 27198 invoked from network); 13 Jun 2004 03:01:58 -0000 Received: from unknown (HELO ori.thedillows.org) (69.1.45.93) by smtp1.knology.net with SMTP; 13 Jun 2004 03:01:58 -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 i5D31vDI005914; Sat, 12 Jun 2004 23:01:57 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i5D31uCu005912; Sat, 12 Jun 2004 23:01:56 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: [0/3] mc_filter on big-endian arch From: David Dillow To: David Stevens Cc: Andrew Morton , Jeff Garzik , Netdev , Roger Luethi In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1087095716.4085.4.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 12 Jun 2004 23:01:56 -0400 X-archive-position: 5885 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: 963 Lines: 20 On Thu, 2004-06-10 at 01:45, David Stevens wrote: > PS - Here's a trivial program that will join a group. If you run this on > one side, then a ping to the multicast address will work when it's in > the group, and stop answering when it exits. There are more general > things that have been around for years for testing-- I just threw this > together just now. (I hope it doesn't have any bugs! :-) ) Should be > suitable for testing hardware multicast address filters... Thank you for sending this program; it saved me having to write my own, and it helped me to demonstrate that multicast already works properly under typhoon. As it turns out, my copy of tcpdump was turning on ALL_MULTI on the interface, even with "-p", and the NIC was responding appropriately. So the multicast packets I saw coming in were legitimate. So, summary, typhoon multicast is OK, on both big and little endian machines. Roger, thanks for spurring me to finally test this. Dave From rl@hellgate.ch Sun Jun 13 03:56:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 03:56:33 -0700 (PDT) Received: from mail5.bluewin.ch (mail5.bluewin.ch [195.186.1.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5DAuNgi005953 for ; Sun, 13 Jun 2004 03:56:24 -0700 Received: from k3.hellgate.ch (62.203.88.33) by mail5.bluewin.ch (Bluewin AG 7.0.028) id 40A46B210035BD33; Thu, 10 Jun 2004 10:20:46 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id B4AF08DC52A; Thu, 10 Jun 2004 12:20:45 +0200 (CEST) Date: Thu, 10 Jun 2004 12:20:45 +0200 From: Roger Luethi To: David Stevens Cc: Andrew Morton , David Dillow , Jeff Garzik , Netdev Subject: Re: [0/3] mc_filter on big-endian arch Message-ID: <20040610102045.GA11616@k3.hellgate.ch> References: <20040607115921.GB32569@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 2.6.7-rc3-bk1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 4463 Lines: 144 On Wed, 09 Jun 2004 23:09:53 -0600, David Stevens wrote: > netdev-bounce@oss.sgi.com wrote on 06/07/2004 04:59:21 AM: > > > One thing maybe worth mentioning: If you want to play with different > > addresses, remember that IP addresses are in decimal notation, ethernet > > in hex. So if you set > > > target# ip maddr add 01:00:5e:00:00:25 dev eth0 > > > the test would be > > > tester# ping -r -I eth0 -t 1 -c 2 224.0.0.37 > > This will add "01:00:5e:00:00:25" to the device multicast address filter, > which will mean the host will receive the packet. But because it doesn't > join the group at the IP level, it'll be dropped and the ping won't be > answered (it isn't for a local address). > > If you want the machine to answer, you need to join the group, which > will conveniently add the hardware multicast address automatically. :-) Correct. The method I described does the trick using standard tools (iproute2, packet sniffer), though. > PS - Here's a trivial program that will join a group. If you run this on > one side, then a ping to the multicast address will work when it's in > the group, and stop answering when it exits. There are more general > things that have been around for years for testing-- I just threw this > together just now. (I hope it doesn't have any bugs! :-) ) Should be > suitable for testing hardware multicast address filters... Sure, why not? Fixed up and added to the How-To below. Roger Multicast Driver Testing Quick How-To (version 0.2) ===================================== Preparation ----------- Make sure the host you are testing replies to broadcasts: target# cat /proc/sys/net/ipv4/icmp_echo_ignore_all 0 target# cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 0 Our test packets need to go to the target host, so either have a route or use ping "-r -I " option: tester# route add -net 224.0.0.0 netmask 240.0.0.0 eth0 Test default group ------------------ Since every multicast capable host interface joins 224.0.0.1, you can already ping your target: tester# ping -r -I eth0 -t 1 -c 2 224.0.0.1 Your target host should answer this (so may your tester, depending on your setup). Join group on Ethernet level ---------------------------- We haven't joined the next group yet, so there should be no answer: tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37 Use packet sniffer to confirm that target is not seeing the request (use -p option for tcpdump or tethereal to prevent promiscuous mode) Now join the group (Ethernet level): target# ip maddr add 01:00:5e:01:01:25 dev eth0 tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37 Use packet sniffer to confirm that target is seeing the request now. Join group on IP level ---------------------- The program below will join a multicast group at IP level and thus at Ethernet level as well -- provided driver and hardware work properly. Group membership end with termination of the program. Remove hardware filter (if any left from previous test): target# ip maddr del 01:00:5e:01:01:25 dev eth0 Join multicast group: target# ./mcjoin eth0 224.1.1.37 tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37 No need for packet sniffer this time, the target will answer since the IP layer is aware of our group membership. -------------------------------------------------------------------------------- /* Purpose: Join a multicast group (for testing) */ /* Author: David Stevens , 2004 */ #include #include #include #include #include #include int main(int argc, char *argv[]) { struct ip_mreqn mreqn; int s; if (argc != 3) { fprintf(stderr, "usage: %s \n", argv[0]); exit(1); } s = socket(PF_INET, SOCK_DGRAM, 0); if (s < 0) { perror("socket"); exit(1); } memset(&mreqn, 0, sizeof(mreqn)); mreqn.imr_ifindex = if_nametoindex(argv[1]); if (!mreqn.imr_ifindex) { fprintf(stderr, "%s: \"%s\" invalid interface\n", argv[0], argv[1]); exit(1); } if (inet_pton(AF_INET, argv[2], &mreqn.imr_multiaddr) <= 0) { fprintf(stderr, "%s: \"%s\" invalid group address\n", argv[0], argv[2]); exit(1); } if (setsockopt(s, SOL_IP, IP_ADD_MEMBERSHIP, &mreqn,sizeof mreqn) < 0) { perror("IP_ADD_MEMBERSHIP"); exit(1); } printf("joined group %s on %s (pausing...)\n", argv[2], argv[1]); fflush(stdout); pause(); exit(0); } -------------------------------------------------------------------------------- From jm@jm.kir.nu Sun Jun 13 13:12:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 13:12:11 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5DKC8gi029149 for ; Sun, 13 Jun 2004 13:12:09 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BZbKI-00025O-6R; Sun, 13 Jun 2004 13:11:34 -0700 Date: Sun, 13 Jun 2004 13:11:34 -0700 From: Jouni Malinen To: "Andonieh, Joe" Cc: Jean Tourrilhes , netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support Message-ID: <20040613201134.GC7327@jm.kir.nu> References: <386CBF9421521B41835E2BF21BEF80B8968D33@hasmsx402.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <386CBF9421521B41835E2BF21BEF80B8968D33@hasmsx402.ger.corp.intel.com> User-Agent: Mutt/1.5.6i X-archive-position: 5887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 2261 Lines: 44 On Wed, Jun 09, 2004 at 09:23:23AM +0300, Andonieh, Joe wrote: > Thinking about access point we need a way to set more than one > cipher suite for the pairwise cipher list (for example mixed mode, which > have both TKIP and CCMP users. > > Another aspect is an AP that wants to support more than one mode of > operation, for example; advertise both WPA and RSN IE, or both WPA .1X > and WPA PSK? These both can use the generic IE mechanism (SIOCSIWGENIE) to configure whatever mode is needed. I'm more used to doing the policy decision in user space (e.g., validating WPA/RSN IE in AssocReq), so there has not been much need in pushing all the information to the driver. Of course, we could change the IW_AUTH_ parameters for cipher and key management suites to use bit field. This limits the number of options to 32, but that should be enough and if not, can be extended in the future. IW_AUTH_ALG_ is already doing this anyway and IW_AUTH_WPA_VERSION_ has only two values, so it works as a bit field already (just needs to be documented as such). > From the Client Perspective; isn't it better Idea for the station decide > or match an access point to connect with depending on the pairwise > cipher only? For example a client that supports CCMP can connect to both > access point where each one may be working in different mode, WPA -- > CCMP as both pair wise and group ciphers or with an AP in mixed mode > which have CCMP as pairwise and TKIP as groupcast cipher. The group cipher could be anything from WEP40 to CCMP and I want to be able to configure the client to reject APs that do not meet the current policy (which might be, "require CCMP"). Doing the selection only based on pairwise cipher would thus not be enough. Changing the IW_AUTH_ parameters to be bitfields would help here, too, for the case of client drivers that want to do the WPA/RSN IE processing in the driver instead of letting Supplicant take care of this. Actually, this reminded me of another thing I forgot: we should add reporting of the exact IE that was used in (Re)AssocReq as a wireless event to the Supplicant so that this case of WPA/RSN IE being generated in the driver is supported. -- Jouni Malinen PGP id EFC895FA From herbert@gondor.apana.org.au Sun Jun 13 16:36:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 16:36:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5DNaRgi002502 for ; Sun, 13 Jun 2004 16:36: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 1BZeW8-0003ES-00; Mon, 14 Jun 2004 09:36:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZeW1-0008Ny-00; Mon, 14 Jun 2004 09:35:53 +1000 From: Herbert Xu To: davem@redhat.com (David S. Miller) Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Cc: schwab@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Organization: Core In-Reply-To: <20040613121514.6b3c1c8a.davem@redhat.com> X-Newsgroups: apana.lists.os.linux.net User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.25-1-686-smp (i686)) Message-Id: Date: Mon, 14 Jun 2004 09:35:53 +1000 X-archive-position: 5888 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: 1681 Lines: 37 David S. Miller wrote: > > diff -Nru a/net/core/dst.c b/net/core/dst.c > --- a/net/core/dst.c 2004-06-13 06:04:49 -07:00 > +++ b/net/core/dst.c 2004-06-13 06:04:49 -07:00 > @@ -230,8 +230,8 @@ > if (event!=NETDEV_DOWN && > dst->output == dst_discard_out) { This is a historical question. What's the dst->output check for? > dst->dev = &loopback_dev; > - dev_put(dev); > dev_hold(&loopback_dev); > + dev_put(dev); > dst->output = dst_discard_out; > if (dst->neighbour && dst->neighbour->dev == dev) { > dst->neighbour->dev = &loopback_dev; > @@ -242,6 +242,8 @@ > dst->input = dst_discard_in; > dst->output = dst_discard_out; > } The loopback_dev stuff takes care of the case when someone is still holding onto the dst. How come we don't have similar code in ifdown? > + if (dst->ops->ifdown) > + dst->ops->ifdown(dst, event != NETDEV_DOWN); What's the rationale for doing this for both UNREGISTER and DOWN? 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 Jun 13 16:42:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 16:42:05 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5DNg0gi002840 for ; Sun, 13 Jun 2004 16:42: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 1BZebk-0003GS-00; Mon, 14 Jun 2004 09:41:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZebe-0008Pf-00; Mon, 14 Jun 2004 09:41:42 +1000 Date: Mon, 14 Jun 2004 09:41:42 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040613234142.GA32329@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5889 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: 368 Lines: 10 BTW, it looks like I missed the original IPv4 idev patch to route.c as well. So could someone please tell me why it was needed in the first place? 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@redhat.com Sun Jun 13 18:41:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 18:41:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E1fngi005202 for ; Sun, 13 Jun 2004 18:41:50 -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 i5E1fai5014739; Sun, 13 Jun 2004 21:41: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 i5E1fa021852; Sun, 13 Jun 2004 21:41: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 i5E1fKgc030717; Sun, 13 Jun 2004 21:41:20 -0400 Date: Sun, 13 Jun 2004 18:36:22 -0700 From: "David S. Miller" To: Herbert Xu Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040613183622.3a814506.davem@redhat.com> In-Reply-To: <20040613234142.GA32329@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5890 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: 329 Lines: 9 On Mon, 14 Jun 2004 09:41:42 +1000 Herbert Xu wrote: > BTW, it looks like I missed the original IPv4 idev patch to route.c > as well. So could someone please tell me why it was needed in the > first place? Because per-device ipv4/ipv6 statistics support is coming. It's necessary infrastructure. From herbert@gondor.apana.org.au Sun Jun 13 18:50:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 18:51:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E1ougi006187 for ; Sun, 13 Jun 2004 18:50: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 1BZgcW-0004K1-00; Mon, 14 Jun 2004 11:50:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZgcG-0002sw-00; Mon, 14 Jun 2004 11:50:28 +1000 Date: Mon, 14 Jun 2004 11:50:13 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614015013.GA11048@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040613183622.3a814506.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5892 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: 722 Lines: 18 On Sun, Jun 13, 2004 at 06:36:22PM -0700, David S. Miller wrote: > On Mon, 14 Jun 2004 09:41:42 +1000 > Herbert Xu wrote: > > > BTW, it looks like I missed the original IPv4 idev patch to route.c > > as well. So could someone please tell me why it was needed in the > > first place? > > Because per-device ipv4/ipv6 statistics support is coming. > It's necessary infrastructure. Thanks. Is there somewhere where I can look at the code that's going to use this infrastructure? -- 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@redhat.com Sun Jun 13 21:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:12:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4Crgi012033 for ; Sun, 13 Jun 2004 21:12:54 -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 i5E4Cgi5015676; Mon, 14 Jun 2004 00:12: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 i5E4Cg012940; Mon, 14 Jun 2004 00:12:42 -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 i5E4CPdT024801; Mon, 14 Jun 2004 00:12:26 -0400 Date: Sun, 13 Jun 2004 21:07:25 -0700 From: "David S. Miller" To: Herbert Xu Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040613210725.70dbd016.davem@redhat.com> In-Reply-To: <20040614015013.GA11048@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5894 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: 719 Lines: 21 On Mon, 14 Jun 2004 11:50:13 +1000 Herbert Xu wrote: > On Sun, Jun 13, 2004 at 06:36:22PM -0700, David S. Miller wrote: > > On Mon, 14 Jun 2004 09:41:42 +1000 > > Herbert Xu wrote: > > > > > BTW, it looks like I missed the original IPv4 idev patch to route.c > > > as well. So could someone please tell me why it was needed in the > > > first place? > > > > Because per-device ipv4/ipv6 statistics support is coming. > > It's necessary infrastructure. > > Thanks. Is there somewhere where I can look at the code that's > going to use this infrastructure? Not written yet, but it will be of the form: idev = rt->idev; SNMP_BUMP_BLAH_BLAH_STAT(idev); From herbert@gondor.apana.org.au Sun Jun 13 21:22:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:22:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4Mbgi012435 for ; Sun, 13 Jun 2004 21:22: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 1BZizI-00052X-00; Mon, 14 Jun 2004 14:22:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZizA-0007TM-00; Mon, 14 Jun 2004 14:22:16 +1000 Date: Mon, 14 Jun 2004 14:22:16 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614042216.GA28669@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040613210725.70dbd016.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5895 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: 1194 Lines: 32 On Sun, Jun 13, 2004 at 09:07:25PM -0700, David S. Miller wrote: > > Not written yet, but it will be of the form: > > idev = rt->idev; > SNMP_BUMP_BLAH_BLAH_STAT(idev); OK, in that case either they all need to check whether idev is NULL before doing this or we'll need to fix ->ifdown to set the dev to something other than NULL. BTW in looking at this I've found two bugs in the dst code wrt cleaning up net devices. 1. The code in dst_dev_event relies on the entries with dev in it getting onto the garbage list before it is called. Unfortunately for routing entries, the flushing is done asynchronusly so it is entirely possible for the entries to get onto the garbage list after dst_dev_event has been called twice (DOWN and then UNREGISTER). This is not fatal though since another GC run will pick them up in at most two minutes. But the user may well be alarmed by those dreaded "waiting for..." errors. 2. dst_dev_event doesn't clean up dst->child 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 davem@redhat.com Sun Jun 13 21:32:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:32:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4Wcgi012885 for ; Sun, 13 Jun 2004 21:32:39 -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 i5E4WOi5019685; Mon, 14 Jun 2004 00:32: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 i5E4WO016007; Mon, 14 Jun 2004 00:32:24 -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 i5E4W802027747; Mon, 14 Jun 2004 00:32:08 -0400 Date: Sun, 13 Jun 2004 21:27:08 -0700 From: "David S. Miller" To: Herbert Xu Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040613212708.1903d54c.davem@redhat.com> In-Reply-To: <20040614042216.GA28669@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5896 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: 1078 Lines: 29 On Mon, 14 Jun 2004 14:22:16 +1000 Herbert Xu wrote: > OK, in that case either they all need to check whether idev is > NULL before doing this or we'll need to fix ->ifdown to set the > dev to something other than NULL. That's correct, I don't exactly how to deal with that race just yet. > BTW in looking at this I've found two bugs in the dst code wrt > cleaning up net devices. > > 1. The code in dst_dev_event relies on the entries with dev in it > getting onto the garbage list before it is called. Unfortunately > for routing entries, the flushing is done asynchronusly so it is > entirely possible for the entries to get onto the garbage list after > dst_dev_event has been called twice (DOWN and then UNREGISTER). > > This is not fatal though since another GC run will pick them up in > at most two minutes. But the user may well be alarmed by those > dreaded "waiting for..." errors. Right. > 2. dst_dev_event doesn't clean up dst->child at all. DST object is disassembled at GC time, so I classift this just like case #1 above. From herbert@gondor.apana.org.au Sun Jun 13 21:42:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:42:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4grgi013871 for ; Sun, 13 Jun 2004 21:42: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 1BZjIy-00057t-00; Mon, 14 Jun 2004 14:42:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZjIu-0007W6-00; Mon, 14 Jun 2004 14:42:40 +1000 Date: Mon, 14 Jun 2004 14:42:40 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614044240.GA28844@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040613212708.1903d54c.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040613212708.1903d54c.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5898 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: 1136 Lines: 29 On Sun, Jun 13, 2004 at 09:27:08PM -0700, David S. Miller wrote: > > > 1. The code in dst_dev_event relies on the entries with dev in it > > getting onto the garbage list before it is called. Unfortunately > > for routing entries, the flushing is done asynchronusly so it is > > entirely possible for the entries to get onto the garbage list after > > dst_dev_event has been called twice (DOWN and then UNREGISTER). > > > > This is not fatal though since another GC run will pick them up in > > at most two minutes. But the user may well be alarmed by those > > dreaded "waiting for..." errors. > > Right. > > > 2. dst_dev_event doesn't clean up dst->child at all. > > DST object is disassembled at GC time, so I classift this just > like case #1 above. Yes. In fact the loopback_dev code in dst_dev_event is also like this. Removing that code will simply defer the dropping of the dev reference to the GC. 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 Jun 13 21:47:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:47:36 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4lVgi014259 for ; Sun, 13 Jun 2004 21:47: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 1BZjNO-00058z-00; Mon, 14 Jun 2004 14:47:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZjNN-0007X1-00; Mon, 14 Jun 2004 14:47:17 +1000 Date: Mon, 14 Jun 2004 14:47:17 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614044717.GA28929@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040613212708.1903d54c.davem@redhat.com> <20040614044240.GA28844@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040614044240.GA28844@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5899 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: 1571 Lines: 37 On Mon, Jun 14, 2004 at 02:42:40PM +1000, herbert wrote: > On Sun, Jun 13, 2004 at 09:27:08PM -0700, David S. Miller wrote: > > > > > 1. The code in dst_dev_event relies on the entries with dev in it > > > getting onto the garbage list before it is called. Unfortunately > > > for routing entries, the flushing is done asynchronusly so it is > > > entirely possible for the entries to get onto the garbage list after > > > dst_dev_event has been called twice (DOWN and then UNREGISTER). > > > > > > This is not fatal though since another GC run will pick them up in > > > at most two minutes. But the user may well be alarmed by those > > > dreaded "waiting for..." errors. > > > > Right. > > > > > 2. dst_dev_event doesn't clean up dst->child at all. > > > > DST object is disassembled at GC time, so I classift this just > > like case #1 above. > > Yes. In fact the loopback_dev code in dst_dev_event is also like > this. Removing that code will simply defer the dropping of the > dev reference to the GC. And there's more :) The work done in ifdown also falls in the same category. Its work will be carried out in the GC anyway. Actually in all these cases it could take a lot more than two minutes if there is a long-living entity (maybe a TCP connection) holding onto the dst. So I guess #1 and #2 should be addressed at some point. 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@redhat.com Sun Jun 13 21:49:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:49:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4nQgi014590 for ; Sun, 13 Jun 2004 21:49:26 -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 i5E4nBi5023198; Mon, 14 Jun 2004 00:49:11 -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 i5E4nB019210; Mon, 14 Jun 2004 00:49:11 -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 i5E4mtEj030861; Mon, 14 Jun 2004 00:48:55 -0400 Date: Sun, 13 Jun 2004 21:43:55 -0700 From: "David S. Miller" To: Herbert Xu Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040613214355.772af3a6.davem@redhat.com> In-Reply-To: <20040614044717.GA28929@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040613212708.1903d54c.davem@redhat.com> <20040614044240.GA28844@gondor.apana.org.au> <20040614044717.GA28929@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5900 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: 586 Lines: 15 On Mon, 14 Jun 2004 14:47:17 +1000 Herbert Xu wrote: > And there's more :) The work done in ifdown also falls in the same > category. Its work will be carried out in the GC anyway. > > Actually in all these cases it could take a lot more than two minutes > if there is a long-living entity (maybe a TCP connection) holding onto > the dst. So I guess #1 and #2 should be addressed at some point. Maybe the solution is to initiate a GC run as soon as possible instead of however long into the future it would have ended up running. Wouldn't that help? From herbert@gondor.apana.org.au Sun Jun 13 21:53:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jun 2004 21:53:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E4rUgi014974 for ; Sun, 13 Jun 2004 21:53: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 1BZjTA-0005BT-00; Mon, 14 Jun 2004 14:53:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZjT6-0007Y4-00; Mon, 14 Jun 2004 14:53:12 +1000 Date: Mon, 14 Jun 2004 14:53:12 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614045312.GA28999@gondor.apana.org.au> References: <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040613212708.1903d54c.davem@redhat.com> <20040614044240.GA28844@gondor.apana.org.au> <20040614044717.GA28929@gondor.apana.org.au> <20040613214355.772af3a6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040613214355.772af3a6.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5901 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: 1117 Lines: 29 On Sun, Jun 13, 2004 at 09:43:55PM -0700, David S. Miller wrote: > On Mon, 14 Jun 2004 14:47:17 +1000 > Herbert Xu wrote: > > > And there's more :) The work done in ifdown also falls in the same > > category. Its work will be carried out in the GC anyway. > > > > Actually in all these cases it could take a lot more than two minutes > > if there is a long-living entity (maybe a TCP connection) holding onto > > the dst. So I guess #1 and #2 should be addressed at some point. > > Maybe the solution is to initiate a GC run as soon as possible > instead of however long into the future it would have ended > up running. > > Wouldn't that help? Not really. The GC is powerless until all those entities drop their references to the dst. That's why we've got this hack in dst_dev_event that sets ->dev to loopback_dev in order to drop the dev reference early. 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 joe.andonieh@intel.com Mon Jun 14 01:56:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 01:56:28 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5E8uJgi023453 for ; Mon, 14 Jun 2004 01:56:21 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i5E8vNle014161; Mon, 14 Jun 2004 08:57:23 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i5E8uUd1016493; Mon, 14 Jun 2004 08:56:59 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061411560506717 ; Mon, 14 Jun 2004 11:56:05 +0300 Received: from hasmsx402.ger.corp.intel.com ([143.185.63.156]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Jun 2004 11:56:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC: Linux wireless extensions and WPA support Date: Mon, 14 Jun 2004 11:56:03 +0300 Message-ID: <386CBF9421521B41835E2BF21BEF80B89B6211@hasmsx402.ger.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: Linux wireless extensions and WPA support Thread-Index: AcRRgrXLo4GYeC+MT7eWuBx2lfN3pgATbupg From: "Andonieh, Joe" To: "Jouni Malinen" Cc: "Jean Tourrilhes" , X-OriginalArrivalTime: 14 Jun 2004 08:56:05.0188 (UTC) FILETIME=[6D0CF040:01C451ED] 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 i5E8uJgi023453 X-archive-position: 5902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joe.andonieh@intel.com Precedence: bulk X-list: netdev Content-Length: 5986 Lines: 138 > These both can use the generic IE mechanism (SIOCSIWGENIE) to configure > Whatever mode is needed. I'm more used to doing the policy decision in > user space (e.g., validating WPA/RSN IE in AssocReq), so there has not > been much need in pushing all the information to the driver. This depend where the AP implementation is as well as the management is handled -- who will send the association failure or success, will you divide the verification of the association between user and kernel space? Moreover what if there is another feature that requires IE (let's say for example WME) In both cases both the supplicant and the authenticator need to know about the association. Authenticator need to track the .1x states and the supplicant need to maintain contact for associated clients. > Of course, we could change the IW_AUTH_ parameters for cipher and key > Management suites to use bit field. This limits the number of options to > 32, but that should be enough and if not, can be extended in the future. > IW_AUTH_ALG_ is already doing this anyway and IW_AUTH_WPA_VERSION_ has > Only two values, so it works as a bit field already (just needs to be > Documented as such). I Guess this is a better approach to have it as a bit mask -- Maybe I s till do not understand the interface correctly, but still I can't see how the user can set the pairwise cipher separately from the group cipher? The interface show +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values */ +#define IW_AUTH_CIPHER_NONE 0 +#define IW_AUTH_CIPHER_WEP40 1 +#define IW_AUTH_CIPHER_TKIP 2 +#define IW_AUTH_CIPHER_CCMP 4 +#define IW_AUTH_CIPHER_WEP104 5 But not specify which is what? > The group cipher could be anything from WEP40 to CCMP and I want to be > able to configure the client to reject APs that do not meet the > current policy (which might be, "require CCMP"). Doing the selection > only based on pairwise cipher would thus not be enough. Maybe we need to add an interface to support both, for example group cipher "Dint care" or "specified"??? Or even select from a group of cipher, kind of allowed list. What do you think? > Changing the IW_AUTH_ parameters to be bit fields would help here, too, > for the case of client drivers that want to do the WPA/RSN IE processing > in the driver instead of letting Supplicant take care of this. Actually, > this reminded me of another thing I forgot: we should add reporting of > the exact IE that was used in (Re)AssocReq as a wireless event to the > Supplicant so that this case of WPA/RSN IE being generated in the > driver is supported. We should have the capability for both, i.e. allow two kind of implementations -- something similar to host AP where everything is handled by the supplicant and also we need to allow the device handle everything, this is sometimes depended on the device design and the driver design the interface should not force it. Moreover we need to think about additional features that require additional IE in the association request which does not handled by the Security supplicant, if we let the supplicant build the association request you do not want it to build the IE for other features (such as WME) I am more comfortable with an interface that allows user space (such as supplicant to append IEs to the association/beacon/probs packets -- the question is how to sync multiple management APPs and who will make the decision for association success or failure. Thanks Joe -----Original Message----- From: Jouni Malinen [mailto:jm@jm.kir.nu] On Behalf Of Jouni Malinen Sent: Sunday, June 13, 2004 11:12 PM To: Andonieh, Joe Cc: Jean Tourrilhes; netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support On Wed, Jun 09, 2004 at 09:23:23AM +0300, Andonieh, Joe wrote: > Thinking about access point we need a way to set more than one > cipher suite for the pairwise cipher list (for example mixed mode, which > have both TKIP and CCMP users. > > Another aspect is an AP that wants to support more than one mode of > operation, for example; advertise both WPA and RSN IE, or both WPA .1X > and WPA PSK? These both can use the generic IE mechanism (SIOCSIWGENIE) to configure whatever mode is needed. I'm more used to doing the policy decision in user space (e.g., validating WPA/RSN IE in AssocReq), so there has not been much need in pushing all the information to the driver. Of course, we could change the IW_AUTH_ parameters for cipher and key management suites to use bit field. This limits the number of options to 32, but that should be enough and if not, can be extended in the future. IW_AUTH_ALG_ is already doing this anyway and IW_AUTH_WPA_VERSION_ has only two values, so it works as a bit field already (just needs to be documented as such). > From the Client Perspective; isn't it better Idea for the station decide > or match an access point to connect with depending on the pairwise > cipher only? For example a client that supports CCMP can connect to both > access point where each one may be working in different mode, WPA -- > CCMP as both pair wise and group ciphers or with an AP in mixed mode > which have CCMP as pairwise and TKIP as groupcast cipher. The group cipher could be anything from WEP40 to CCMP and I want to be able to configure the client to reject APs that do not meet the current policy (which might be, "require CCMP"). Doing the selection only based on pairwise cipher would thus not be enough. Changing the IW_AUTH_ parameters to be bit fields would help here, too, for the case of client drivers that want to do the WPA/RSN IE processing in the driver instead of letting Supplicant take care of this. Actually, this reminded me of another thing I forgot: we should add reporting of the exact IE that was used in (Re)AssocReq as a wireless event to the Supplicant so that this case of WPA/RSN IE being generated in the driver is supported. -- Jouni Malinen PGP id EFC895FA From herbert@gondor.apana.org.au Mon Jun 14 03:29:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 03:29:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EATHgi028170 for ; Mon, 14 Jun 2004 03:29:19 -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 1BZoi8-0007mU-00; Mon, 14 Jun 2004 20:29:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZoi2-0003DK-00; Mon, 14 Jun 2004 20:28:58 +1000 Date: Mon, 14 Jun 2004 20:28:58 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614102858.GA12343@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040614042216.GA28669@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5903 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: 744 Lines: 17 On Mon, Jun 14, 2004 at 02:22:16PM +1000, herbert wrote: > > 1. The code in dst_dev_event relies on the entries with dev in it > getting onto the garbage list before it is called. Unfortunately > for routing entries, the flushing is done asynchronusly so it is > entirely possible for the entries to get onto the garbage list after > dst_dev_event has been called twice (DOWN and then UNREGISTER). Actually this can't happen since fib_netdev_event will do an immediate flush. So it's only #2 or IPsec that's a problem. 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 akpm@osdl.org Mon Jun 14 03:41:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 03:42:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EAfvgi028699 for ; Mon, 14 Jun 2004 03:41:58 -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 i5EAfEr27805; Mon, 14 Jun 2004 03:41:14 -0700 Date: Mon, 14 Jun 2004 03:40:27 -0700 From: Andrew Morton To: Roger Luethi Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Restructure reset code Message-Id: <20040614034027.3598a475.akpm@osdl.org> In-Reply-To: <20040614100326.GA32763@k3.hellgate.ch> References: <20040602115920.GA17634@k3.hellgate.ch> <40BE2DE0.4040102@pobox.com> <20040614100326.GA32763@k3.hellgate.ch> 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: 5904 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: 127 Lines: 5 Roger Luethi wrote: > > what is missing to move forward in -mm? Sending the patches would be a good start ;) From herbert@gondor.apana.org.au Mon Jun 14 05:44:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 05:44:27 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ECiJgi005643 for ; Mon, 14 Jun 2004 05:44: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 1BZqor-0000U9-00; Mon, 14 Jun 2004 22:44:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BZqok-0000Fy-00; Mon, 14 Jun 2004 22:44:02 +1000 Date: Mon, 14 Jun 2004 22:44:02 +1000 To: "David S. Miller" Cc: schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, kuznet@ms2.inr.ac.ru Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040614124402.GA28519@gondor.apana.org.au> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20040614102858.GA12343@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5905 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: 3649 Lines: 114 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 14, 2004 at 08:28:58PM +1000, herbert wrote: > On Mon, Jun 14, 2004 at 02:22:16PM +1000, herbert wrote: > > > > 1. The code in dst_dev_event relies on the entries with dev in it > > getting onto the garbage list before it is called. Unfortunately > > for routing entries, the flushing is done asynchronusly so it is > > entirely possible for the entries to get onto the garbage list after > > dst_dev_event has been called twice (DOWN and then UNREGISTER). > > Actually this can't happen since fib_netdev_event will do an > immediate flush. So it's only #2 or IPsec that's a problem. And even there it's not too bad as it only happens if there are more than two IPsec dst's in a row, e.g., ESP/IPCOMP. Here is a patch to do the same loopback_dev hack for child dst's. I've also taken the liberty to remove the bogus dst->output check. I've tested it with ESP/IPCOMP and I can confirm that it allows me to remove my NIC module if when I've got a TCP connection over it. Without it the removal hangs. Alexey, if I've missed any subtle piece of logic there, please scream :) 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=p ===== net/core/dst.c 1.17 vs edited ===== --- 1.17/net/core/dst.c 2004-06-13 03:51:53 +10:00 +++ edited/net/core/dst.c 2004-06-14 22:39:51 +10:00 @@ -210,6 +210,36 @@ return NULL; } +/* Dirty hack. We did it in 2.2 (in __dst_free), + * we have _very_ good reasons not to repeat + * this mistake in 2.3, but we have no choice + * now. _It_ _is_ _explicit_ _deliberate_ + * _race_ _condition_. + * + * Commented and originally written by Alexey. + */ +static void dst_ifdown(struct dst_entry *dst, int unregister) +{ + struct net_device *dev = dst->dev; + + do { + if (unregister) { + dst->dev = &loopback_dev; + dev_hold(&loopback_dev); + dev_put(dev); + if (dst->neighbour && dst->neighbour->dev == dev) { + dst->neighbour->dev = &loopback_dev; + dev_put(dev); + dev_hold(&loopback_dev); + } + } + + if (dst->ops->ifdown) + dst->ops->ifdown(dst, unregister); + } while ((dst = dst->child) && dst->flags & DST_NOHASH && + dst->dev == dev); +} + static int dst_dev_event(struct notifier_block *this, unsigned long event, void *ptr) { struct net_device *dev = ptr; @@ -221,29 +251,11 @@ spin_lock_bh(&dst_lock); for (dst = dst_garbage_list; dst; dst = dst->next) { if (dst->dev == dev) { - /* Dirty hack. We did it in 2.2 (in __dst_free), - we have _very_ good reasons not to repeat - this mistake in 2.3, but we have no choice - now. _It_ _is_ _explicit_ _deliberate_ - _race_ _condition_. - */ - if (event!=NETDEV_DOWN && - dst->output == dst_discard_out) { - dst->dev = &loopback_dev; - dev_hold(&loopback_dev); - dev_put(dev); - dst->output = dst_discard_out; - if (dst->neighbour && dst->neighbour->dev == dev) { - dst->neighbour->dev = &loopback_dev; - dev_put(dev); - dev_hold(&loopback_dev); - } - } else { + if (event == NETDEV_DOWN) { dst->input = dst_discard_in; dst->output = dst_discard_out; } - if (dst->ops->ifdown) - dst->ops->ifdown(dst, event != NETDEV_DOWN); + dst_ifdown(dst, event != NETDEV_DOWN); } } spin_unlock_bh(&dst_lock); --ew6BAiZeqk4r7MaW-- From marc.herbert@free.fr Mon Jun 14 06:10:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 06:10:49 -0700 (PDT) Received: from relay03s.ntr.oleane.net (relay03s.ntr.oleane.net [194.2.8.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EDAjgi006452 for ; Mon, 14 Jun 2004 06:10:45 -0700 Received: from [10.0.0.3] ([194.2.198.253]) by relay03s.ntr.oleane.net with ESMTP id i5EDAdFe017493; Mon, 14 Jun 2004 15:10:39 +0200 Date: Mon, 14 Jun 2004 15:11:15 +0200 (CEST) From: Marc Herbert X-X-Sender: mherbert@fcat To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics In-Reply-To: <20040609151246.1c28c4d9.davem@redhat.com> Message-ID: References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> <40C77C70.5070409@tmr.com> <20040609213850.GA17243@k3.hellgate.ch> <20040609151246.1c28c4d9.davem@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc.herbert@free.fr Precedence: bulk X-list: netdev Content-Length: 1935 Lines: 49 On Wed, 9 Jun 2004, David S. Miller wrote: > On Wed, 9 Jun 2004 23:38:50 +0200 > Roger Luethi wrote: > > > I just killed the module parameters in my via-rhine development > > tree. > > That is absolutely the correct thing to do, module parameters for > link settings are %100 deprecated, people need to use ethtool for > everything. This is precisely the reason why I am concerned about having "rich" ethtool semantics. A unified, standard interface is great,... as long it does not leave behind some features, like setting the advertised values in autoneg. As a user of these features, I hope driver developers will NOT remove those module_param features that cannot migrated to ethtool. On Tue, 8 Jun 2004, Marc Herbert wrote: > > On Mon, 7 Jun 2004 23:28:04 +0200 > > Roger Luethi wrote: > > > > > What is the correct response if a user passes ethtool speed or duplex > > > arguments while autoneg is on? Some possible answers are: > > > c) Change advertised value accordingly and initiate new negotiation. > I find the c) feature very convenient. For instance it allows reliably > downgrading a link connected to a switch without having to fiddle with > the configuration of the switch, something which is usually (pick your > favourites) non-standard, painful, not authorized, not implemented, > buggy,... In case any one wondered: probably the most common motivation for manually downgrading a link is when the cabling is found to be not "good enough" for the max common speed of the two transceivers. (see "Gigabit Ethernet - Rich Seifert, section 8.2.3") See also: "Running 1000BASE-T: Gigabit Ethernet over Copper" http://www.10gea.org/GEA_copper_0999_rev-wp.pdf "The 1000BASE-T Task Force and the cabling companies estimate that less than 10 percent of the installed base of Category 5 cable was improperly installed," I find "less than 10 percent" not so negligible. From DanE@aiinet.com Mon Jun 14 06:39:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 06:39:17 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EDdBgi007189 for ; Mon, 14 Jun 2004 06:39:12 -0700 Received: by AIMAIL1.ai.aiinet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jun 2004 09:40:24 -0400 Message-ID: From: "Eble, Dan" To: "'Krzysztof Halasa'" Cc: "'netdev@oss.sgi.com'" Subject: RE: RFC: Cisco HDLC bridging Date: Mon, 14 Jun 2004 09:40:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 5907 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 Content-Length: 2211 Lines: 45 Krzysztof, I thought you had dropped off the face of the earth. Good to hear from you again. Did you ever see my changes to make the HDLC generic layer use the PPP generic layer instead of syncppp.c? > obvious to newcomers. And I would make it conditional (for example, > with CONFIG_ option _and_ runtime ioctl creating the slave device). OK. I will attempt to add CONFIG_HDLC_CISCO_ETH and IF_PROTO_CISCO_ADD_ETH. IF_PROTO_CISCO_ADD_ETH will return the name of the new device, probably "hdlcXeth0". > How are the packets encapsulated? What about 802.1q VLANs? The packets are put directly into the payload of the Cisco HDLC frame. The protocol number in the Cisco header is 0x6558. I don't remember if the FCS is included or not. I expect it is, but that should be obvious when I hook up to a Cisco device. I'm not sure about VLAN frames, or about IEEE spanning tree; I plan to treat them like all other packets until I learn that there is another way. > However I don't feel like convinced to use the second network device. > Certainly there is no problem with tcpdump/libpcap, we could have > Cisco hdlcX device with SLARPs, Ethernet framing, regular IPv4/6 > and anything we want. I thought tcpdump/libpcap only looked at the device type, so that if we sent non-eth packets up an eth interface, tcpdump would try to interpret them as eth packets. My primary reason for wanting a second device is to be sure not to discard information that is helpful/necessary for troubleshooting; so, if receiving packets with diverse header types is not going to mess things up, I would definitely prefer using only one device, because it is simpler to configure. The case of using a Cisco HDLC link for bridged ethernet *and* IP *and* other things at the same time does not seem very useful. > The only problem I can see (a serious one, though) is the protocol > "routing" in Linux. If we "ip addr add" IP address to hdlcX, does > it mean we want native IP or IP/Ethernet? It would be nice to be able > to: > ifconfig hdlc0 10.0.0.1/24 hw cisco-hdlc > ifconfig hdlc0 10.0.1.1/24 hw ether We could just use "sethdlc hdlc0 cisco-eth" and not worry about distinguishing in ifconfig, right? From rl@hellgate.ch Mon Jun 14 09:33:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 09:33:36 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EGXUgi015442 for ; Mon, 14 Jun 2004 09:33:31 -0700 Received: from k3.hellgate.ch (62.203.176.143) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A68003B490E; Mon, 14 Jun 2004 11:00:35 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 478649124A5; Mon, 14 Jun 2004 13:00:35 +0200 (CEST) Date: Mon, 14 Jun 2004 13:00:35 +0200 From: Roger Luethi To: Andrew Morton Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Restructure reset code Message-ID: <20040614110035.GA3258@k3.hellgate.ch> References: <20040602115920.GA17634@k3.hellgate.ch> <40BE2DE0.4040102@pobox.com> <20040614100326.GA32763@k3.hellgate.ch> <20040614034027.3598a475.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040614034027.3598a475.akpm@osdl.org> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 410 Lines: 12 On Mon, 14 Jun 2004 03:40:27 -0700, Andrew Morton wrote: > Roger Luethi wrote: > > > > what is missing to move forward in -mm? > > Sending the patches would be a good start ;) I would have to rediff and fix them all against a driver without patch [9/9] from the previous series. ATM I can't see a good reason for doing that since for everything I know, that patch was perfectly fine. Roger From shemminger@osdl.org Mon Jun 14 09:43:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 09:43:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EGh1gi015873 for ; Mon, 14 Jun 2004 09:43:02 -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 i5EGeYr22983; Mon, 14 Jun 2004 09:40:34 -0700 Date: Mon, 14 Jun 2004 09:40:34 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] fix oops from acenic ethtool Message-Id: <20040614094034.7f06445c@dell_ss3.pdx.osdl.net> In-Reply-To: <40C9022F.8050102@pobox.com> References: <20040604145333.34d1600f@dell_ss3.pdx.osdl.net> <40C9022F.8050102@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: 5909 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: 9173 Lines: 322 Here is a revised version of the acenic patch: * use ethtool_ops - solves OOPS on boot up * put firmware and driver version in correct place in ethtool info response * get rid of #ifdef SIOCETHTOOL Signed-off-by: Stephen Hemminger diff -urN -X dontdiff linux-2.6/drivers/net/acenic.c tcp-2.6/drivers/net/acenic.c --- linux-2.6/drivers/net/acenic.c 2004-05-28 08:33:52.000000000 -0700 +++ tcp-2.6/drivers/net/acenic.c 2004-06-14 08:29:56.237392072 -0700 @@ -71,9 +71,7 @@ #include #endif -#ifdef SIOCETHTOOL #include -#endif #include #include @@ -438,11 +436,22 @@ MODULE_PARM_DESC(max_rx_desc, "AceNIC/3C985/GA620 max number of receive descriptors to wait"); MODULE_PARM_DESC(tx_ratio, "AceNIC/3C985/GA620 ratio of NIC memory used for TX/RX descriptors (range 0-63)"); +#define DRIVER_VERSION "0.92" static char version[] __initdata = - "acenic.c: v0.92 08/05/2002 Jes Sorensen, linux-acenic@SunSITE.dk\n" + "acenic.c: v" DRIVER_VERSION "08/05/2002 Jes Sorensen, linux-acenic@SunSITE.dk\n" " http://home.cern.ch/~jes/gige/acenic.html\n"; +static int ace_get_settings(struct net_device *, struct ethtool_cmd *); +static int ace_set_settings(struct net_device *, struct ethtool_cmd *); +static void ace_get_drvinfo(struct net_device *, struct ethtool_drvinfo *); + +static struct ethtool_ops ace_ethtool_ops = { + .get_settings = ace_get_settings, + .set_settings = ace_set_settings, + .get_drvinfo = ace_get_drvinfo, +}; + static int __devinit acenic_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) { @@ -480,7 +489,7 @@ dev->hard_start_xmit = &ace_start_xmit; dev->get_stats = &ace_get_stats; dev->set_multicast_list = &ace_set_multicast_list; - dev->do_ioctl = &ace_ioctl; + SET_ETHTOOL_OPS(dev, &ace_ethtool_ops); dev->set_mac_address = &ace_set_mac_addr; dev->change_mtu = &ace_change_mtu; @@ -2688,146 +2697,137 @@ return 0; } - -static int ace_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static int ace_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { struct ace_private *ap = dev->priv; struct ace_regs *regs = ap->regs; -#ifdef SIOCETHTOOL - struct ethtool_cmd ecmd; - u32 link, speed; + u32 link; - if (cmd != SIOCETHTOOL) - return -EOPNOTSUPP; - if (copy_from_user(&ecmd, ifr->ifr_data, sizeof(ecmd))) - return -EFAULT; - switch (ecmd.cmd) { - case ETHTOOL_GSET: - ecmd.supported = - (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | - SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | - SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full | - SUPPORTED_Autoneg | SUPPORTED_FIBRE); - - ecmd.port = PORT_FIBRE; - ecmd.transceiver = XCVR_INTERNAL; - ecmd.phy_address = 0; - - link = readl(®s->GigLnkState); - if (link & LNK_1000MB) - ecmd.speed = SPEED_1000; - else { - link = readl(®s->FastLnkState); - if (link & LNK_100MB) - ecmd.speed = SPEED_100; - else if (link & LNK_100MB) - ecmd.speed = SPEED_10; - else - ecmd.speed = 0; - } - if (link & LNK_FULL_DUPLEX) - ecmd.duplex = DUPLEX_FULL; + memset(ecmd, 0, sizeof(struct ethtool_cmd)); + ecmd->supported = + (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full | + SUPPORTED_Autoneg | SUPPORTED_FIBRE); + + ecmd->port = PORT_FIBRE; + ecmd->transceiver = XCVR_INTERNAL; + + link = readl(®s->GigLnkState); + if (link & LNK_1000MB) + ecmd->speed = SPEED_1000; + else { + link = readl(®s->FastLnkState); + if (link & LNK_100MB) + ecmd->speed = SPEED_100; + else if (link & LNK_100MB) + ecmd->speed = SPEED_10; else - ecmd.duplex = DUPLEX_HALF; + ecmd->speed = 0; + } + if (link & LNK_FULL_DUPLEX) + ecmd->duplex = DUPLEX_FULL; + else + ecmd->duplex = DUPLEX_HALF; - if (link & LNK_NEGOTIATE) - ecmd.autoneg = AUTONEG_ENABLE; - else - ecmd.autoneg = AUTONEG_DISABLE; + if (link & LNK_NEGOTIATE) + ecmd->autoneg = AUTONEG_ENABLE; + else + ecmd->autoneg = AUTONEG_DISABLE; #if 0 - /* - * Current struct ethtool_cmd is insufficient - */ - ecmd.trace = readl(®s->TuneTrace); + /* + * Current struct ethtool_cmd is insufficient + */ + ecmd->trace = readl(®s->TuneTrace); - ecmd.txcoal = readl(®s->TuneTxCoalTicks); - ecmd.rxcoal = readl(®s->TuneRxCoalTicks); + ecmd->txcoal = readl(®s->TuneTxCoalTicks); + ecmd->rxcoal = readl(®s->TuneRxCoalTicks); #endif - ecmd.maxtxpkt = readl(®s->TuneMaxTxDesc); - ecmd.maxrxpkt = readl(®s->TuneMaxRxDesc); + ecmd->maxtxpkt = readl(®s->TuneMaxTxDesc); + ecmd->maxrxpkt = readl(®s->TuneMaxRxDesc); - if(copy_to_user(ifr->ifr_data, &ecmd, sizeof(ecmd))) - return -EFAULT; - return 0; - - case ETHTOOL_SSET: - link = readl(®s->GigLnkState); - if (link & LNK_1000MB) - speed = SPEED_1000; - else { - link = readl(®s->FastLnkState); - if (link & LNK_100MB) - speed = SPEED_100; - else if (link & LNK_100MB) - speed = SPEED_10; - else - speed = SPEED_100; - } + return 0; +} - link = LNK_ENABLE | LNK_1000MB | LNK_100MB | LNK_10MB | - LNK_RX_FLOW_CTL_Y | LNK_NEG_FCTL; - if (!ACE_IS_TIGON_I(ap)) - link |= LNK_TX_FLOW_CTL_Y; - if (ecmd.autoneg == AUTONEG_ENABLE) - link |= LNK_NEGOTIATE; - if (ecmd.speed != speed) { - link &= ~(LNK_1000MB | LNK_100MB | LNK_10MB); - switch (speed) { - case SPEED_1000: - link |= LNK_1000MB; - break; - case SPEED_100: - link |= LNK_100MB; - break; - case SPEED_10: - link |= LNK_10MB; - break; - } +static int ace_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd) +{ + struct ace_private *ap = dev->priv; + struct ace_regs *regs = ap->regs; + u32 link, speed; + + link = readl(®s->GigLnkState); + if (link & LNK_1000MB) + speed = SPEED_1000; + else { + link = readl(®s->FastLnkState); + if (link & LNK_100MB) + speed = SPEED_100; + else if (link & LNK_100MB) + speed = SPEED_10; + else + speed = SPEED_100; + } + + link = LNK_ENABLE | LNK_1000MB | LNK_100MB | LNK_10MB | + LNK_RX_FLOW_CTL_Y | LNK_NEG_FCTL; + if (!ACE_IS_TIGON_I(ap)) + link |= LNK_TX_FLOW_CTL_Y; + if (ecmd->autoneg == AUTONEG_ENABLE) + link |= LNK_NEGOTIATE; + if (ecmd->speed != speed) { + link &= ~(LNK_1000MB | LNK_100MB | LNK_10MB); + switch (speed) { + case SPEED_1000: + link |= LNK_1000MB; + break; + case SPEED_100: + link |= LNK_100MB; + break; + case SPEED_10: + link |= LNK_10MB; + break; } - if (ecmd.duplex == DUPLEX_FULL) - link |= LNK_FULL_DUPLEX; + } - if (link != ap->link) { - struct cmd cmd; - printk(KERN_INFO "%s: Renegotiating link state\n", - dev->name); + if (ecmd->duplex == DUPLEX_FULL) + link |= LNK_FULL_DUPLEX; - ap->link = link; - writel(link, ®s->TuneLink); - if (!ACE_IS_TIGON_I(ap)) - writel(link, ®s->TuneFastLink); - wmb(); + if (link != ap->link) { + struct cmd cmd; + printk(KERN_INFO "%s: Renegotiating link state\n", + dev->name); - cmd.evt = C_LNK_NEGOTIATION; - cmd.code = 0; - cmd.idx = 0; - ace_issue_cmd(regs, &cmd); - } - return 0; + ap->link = link; + writel(link, ®s->TuneLink); + if (!ACE_IS_TIGON_I(ap)) + writel(link, ®s->TuneFastLink); + wmb(); - case ETHTOOL_GDRVINFO: { - struct ethtool_drvinfo info = {ETHTOOL_GDRVINFO}; - strncpy(info.driver, "acenic", sizeof(info.driver) - 1); - sprintf(info.fw_version, "%i.%i.%i", - tigonFwReleaseMajor, tigonFwReleaseMinor, - tigonFwReleaseFix); - strncpy(info.version, version, sizeof(info.version) - 1); - if (ap && ap->pdev) - strcpy(info.bus_info, pci_name(ap->pdev)); - if (copy_to_user(ifr->ifr_data, &info, sizeof(info))) - return -EFAULT; - return 0; - } - default: - break; + cmd.evt = C_LNK_NEGOTIATION; + cmd.code = 0; + cmd.idx = 0; + ace_issue_cmd(regs, &cmd); } - -#endif - - return -EOPNOTSUPP; + return 0; } +static void ace_get_drvinfo(struct net_device *dev, + struct ethtool_drvinfo *info) +{ + struct ace_private *ap = dev->priv; + + strcpy(info->driver, "acenic"); + strcpy(info->version, DRIVER_VERSION); + snprintf(info->fw_version, sizeof(info->fw_version), "%i.%i.%i", + tigonFwReleaseMajor, tigonFwReleaseMinor, + tigonFwReleaseFix); + + if (ap->pdev) + strlcpy(info->bus_info, pci_name(ap->pdev), + sizeof(info->bus_info)); + +} /* * Set the hardware MAC address. diff -urN -X dontdiff linux-2.6/drivers/net/acenic.h tcp-2.6/drivers/net/acenic.h --- linux-2.6/drivers/net/acenic.h 2004-03-31 11:03:17.000000000 -0800 +++ tcp-2.6/drivers/net/acenic.h 2004-06-04 14:19:44.000000000 -0700 @@ -790,7 +790,6 @@ static void ace_dump_trace(struct ace_private *ap); static void ace_set_multicast_list(struct net_device *dev); static int ace_change_mtu(struct net_device *dev, int new_mtu); -static int ace_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd); static int ace_set_mac_addr(struct net_device *dev, void *p); static void ace_set_rxtx_parms(struct net_device *dev, int jumbo); static int ace_allocate_descriptors(struct net_device *dev); From david@dgreaves.com Mon Jun 14 09:47:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 09:47:19 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EGlGgi016277 for ; Mon, 14 Jun 2004 09:47:16 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 5A27AE6A97; Mon, 14 Jun 2004 17:47:09 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28574-02; Mon, 14 Jun 2004 17:47:09 +0100 (BST) Received: from oak.dgreaves.com (modem-1510.karuhiruhi.dialup.pol.co.uk [81.78.133.230]) by mail.ukfsn.org (Postfix) with ESMTP id 9304FE6A96; Mon, 14 Jun 2004 17:47:08 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.121]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BZudq-0006Dp-35; Mon, 14 Jun 2004 17:49:02 +0100 Message-ID: <40CDD68C.8070509@dgreaves.com> Date: Mon, 14 Jun 2004 17:47:08 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: shemminger@osdl.org, scott.feldman@intel.com Cc: netdev@oss.sgi.com Subject: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 1523 Lines: 46 Hi I have 2 machines with Intel/Pro 1000MT cards. One machine seems to work fine (AFAIK), the other has major problems. I've swapped the cards and the problem stays on the machine. I'm using version 5.2.39-k2 from the stock 2.6.6 kernel on both machines. Any sustained traffic causes repeated: Jun 14 16:29:14 ash kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 14 16:29:17 ash kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex Jun 14 16:29:17 ash kernel: nfs: server cu OK I had a pair of Realtek r8169s that worked fine but only gave me 10Mb/s so I exchanged them for the Intel/Pro cards in the hope of something better - now, even with scp's rate limiter as low as 10kb/s this it still occurs. I have played with all the module parameters and not found anything that affects it at 1Gbps Even dropping to 100Mbps: Jun 14 17:33:03 ash kernel: e1000: eth0 NIC Link is Up 100 Mbps Full Duplex Jun 14 17:33:33 ash kernel: NETDEV WATCHDOG: eth0: transmit timed out it can do 10Mbs: scp reports a throughput of 1.0Mb/s (... less than thrilling) however scp now transfers a few Mb and says: Disconnecting: Corrupted MAC on input. I found this mail: http://oss.sgi.com/projects/netdev/archive/2004-06/msg00256.html from Stephen which appears to reverse this mail: http://marc.theaimsgroup.com/?l=linux-kernel&m=107516205706542&w=2 from Scott which I gather was supposed to correct this problem :) I have seen no suggestions about other subsystems (eg ACPI etc) that could also be tried. David From thockin@www.hockin.org Mon Jun 14 10:01:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 10:01:57 -0700 (PDT) Received: from www.hockin.org ([66.35.79.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EH1lgi016829 for ; Mon, 14 Jun 2004 10:01:48 -0700 Received: (from thockin@localhost) by www.hockin.org (8.11.6/8.11.6) id i5EH1cL00524; Mon, 14 Jun 2004 10:01:38 -0700 Date: Mon, 14 Jun 2004 10:01:38 -0700 From: Tim Hockin To: Marc Herbert Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics Message-ID: <20040614170138.GA32594@hockin.org> References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> <40C77C70.5070409@tmr.com> <20040609213850.GA17243@k3.hellgate.ch> <20040609151246.1c28c4d9.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-archive-position: 5911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thockin@hockin.org Precedence: bulk X-list: netdev Content-Length: 701 Lines: 18 On Mon, Jun 14, 2004 at 03:11:15PM +0200, Marc Herbert wrote: > > That is absolutely the correct thing to do, module parameters for > > link settings are %100 deprecated, people need to use ethtool for > > everything. > > This is precisely the reason why I am concerned about having "rich" > ethtool semantics. A unified, standard interface is great,... as long > it does not leave behind some features, like setting the advertised > values in autoneg. As a user of these features, I hope driver > developers will NOT remove those module_param features that cannot > migrated to ethtool. So propose a sane semantic that handles all three cases: * autoneg on * autoneg off * autoneg on but limited From akepner@sgi.com Mon Jun 14 10:21:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 10:21:50 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EHLigi017467 for ; Mon, 14 Jun 2004 10:21:44 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5EH8uiv027520 for ; Mon, 14 Jun 2004 12:08:57 -0500 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i5EH8el716794414; Mon, 14 Jun 2004 10:08:56 -0700 (PDT) Date: Mon, 14 Jun 2004 10:03:52 -0700 From: Arthur Kepner X-X-Sender: akepner@neteng.engr.sgi.com To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [RFC/PATCH] lockless loopback patch for 2.6 (version 2) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1072017398-1816748115-1087232632=:479900" X-archive-position: 5912 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: 13830 Lines: 262 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. ---1072017398-1816748115-1087232632=:479900 Content-Type: TEXT/PLAIN; charset=US-ASCII About three weeks ago I sent a patch to address lock contention on the loopback device. I received several constructive criticisms and now have a second version which is attached. The patch is against 2.6. Why this is useful ------------------ Lock contention on the loopback can be a serious performance problem on large (>32 cpu) multiprocessor systems, even leading to near-livelock. There is supporting lockstat data in the email which accompanied my first patch. Issues addressed in the second version of the patch --------------------------------------------------- Here's a summary of the comments on the first patch and the actions that were taken (let me know if I missed anything): 1) It prevented the use of queueing disciplines on the loopback. Ugh, that it did. The new patch makes struct Qdisc an "rcu structure". It isn't deleted until it's known that no references to it exist (or at least none should exist.) This allows lockless read access (to a possibly stale Qdisc.) This gives the performance benefits of the previous patch, and doesn't prevent the use of queueing disciplines on the loopback. (I'd especially appreciate comments on the interaction with Qdiscs.) 2) Should use per-cpu stats rather than slots in an array. Done. 3) It's ugly It's now beautiful ;-) There was also the suggestion of creating multiple loopback devices, but I preferred not to do that. -- Arthur ---1072017398-1816748115-1087232632=:479900 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="lockless_loopback.patch.2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: lockless_loopback.patch.2 Content-Disposition: attachment; filename="lockless_loopback.patch.2" LS0tIGxpbnV4Lm9yaWcvL2RyaXZlcnMvbmV0L2xvb3BiYWNrLmMJMjAwNC0w Ni0wOCAxNTozNjo1MC4wMDAwMDAwMDAgLTA3MDANCisrKyBsaW51eC8vZHJp dmVycy9uZXQvbG9vcGJhY2suYwkyMDA0LTA2LTExIDE0OjA0OjMzLjAwMDAw MDAwMCAtMDcwMA0KQEAgLTU2LDYgKzU2LDcgQEANCiAjaW5jbHVkZSA8bGlu dXgvaXAuaD4NCiAjaW5jbHVkZSA8bGludXgvdGNwLmg+DQogDQorc3RhdGlj IHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpsb29wYmFja19zdGF0czsNCiAN CiAjZGVmaW5lIExPT1BCQUNLX09WRVJIRUFEICgxMjggKyBNQVhfSEVBREVS ICsgMTYgKyAxNikNCiANCkBAIC0xMTcsMTMgKzExOCwxNyBAQA0KIAlkZXZf a2ZyZWVfc2tiKHNrYik7DQogfQ0KIA0KKyNkZWZpbmUgTE9PUEJBQ0tfU1RB VF9JTkMoZmllbGQpCQkJCVwNCisJKHBlcl9jcHVfcHRyKGxvb3BiYWNrX3N0 YXRzLCBzbXBfcHJvY2Vzc29yX2lkKCkpLT5maWVsZCsrKQ0KKyNkZWZpbmUg TE9PUEJBQ0tfU1RBVF9BREQoZmllbGQsIG4pCQkJCVwNCisJKHBlcl9jcHVf cHRyKGxvb3BiYWNrX3N0YXRzLCBzbXBfcHJvY2Vzc29yX2lkKCkpLT5maWVs ZCArPSBuKQ0KKw0KIC8qDQogICogVGhlIGhpZ2hlciBsZXZlbHMgdGFrZSBj YXJlIG9mIG1ha2luZyB0aGlzIG5vbi1yZWVudHJhbnQgKGl0J3MNCiAgKiBj YWxsZWQgd2l0aCBiaCdzIGRpc2FibGVkKS4NCiAgKi8NCiBzdGF0aWMgaW50 IGxvb3BiYWNrX3htaXQoc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IG5l dF9kZXZpY2UgKmRldikNCiB7DQotCXN0cnVjdCBuZXRfZGV2aWNlX3N0YXRz ICpzdGF0cyA9IGRldi0+cHJpdjsNCiANCiAJc2tiX29ycGhhbihza2IpOw0K IA0KQEAgLTE0MiwxMSArMTQ3LDExIEBADQogCX0NCiANCiAJZGV2LT5sYXN0 X3J4ID0gamlmZmllczsNCi0JaWYgKGxpa2VseShzdGF0cykpIHsNCi0JCXN0 YXRzLT5yeF9ieXRlcys9c2tiLT5sZW47DQotCQlzdGF0cy0+dHhfYnl0ZXMr PXNrYi0+bGVuOw0KLQkJc3RhdHMtPnJ4X3BhY2tldHMrKzsNCi0JCXN0YXRz LT50eF9wYWNrZXRzKys7DQorCWlmIChsaWtlbHkobG9vcGJhY2tfc3RhdHMp KSB7DQorCQlMT09QQkFDS19TVEFUX0FERChyeF9ieXRlcywgc2tiLT5sZW4p Ow0KKwkJTE9PUEJBQ0tfU1RBVF9BREQodHhfYnl0ZXMsIHNrYi0+bGVuKTsN CisJCUxPT1BCQUNLX1NUQVRfSU5DKHJ4X3BhY2tldHMpOw0KKwkJTE9PUEJB Q0tfU1RBVF9JTkModHhfcGFja2V0cyk7DQogCX0NCiANCiAJbmV0aWZfcngo c2tiKTsNCkBAIC0xNTYsNyArMTYxLDI4IEBADQogDQogc3RhdGljIHN0cnVj dCBuZXRfZGV2aWNlX3N0YXRzICpnZXRfc3RhdHMoc3RydWN0IG5ldF9kZXZp Y2UgKmRldikNCiB7DQotCXJldHVybiAoc3RydWN0IG5ldF9kZXZpY2Vfc3Rh dHMgKilkZXYtPnByaXY7DQorCXN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpz dGF0cyA9IGRldi0+cHJpdjsNCisJaW50IGk7DQorDQorCWlmICh1bmxpa2Vs eSghc3RhdHMpKSB7DQorCQlyZXR1cm4gTlVMTDsNCisJfQ0KKw0KKwltZW1z ZXQoc3RhdHMsIDAsIHNpemVvZihzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cykp Ow0KKwlpZiAodW5saWtlbHkoIWxvb3BiYWNrX3N0YXRzKSkgew0KKwkJcmV0 dXJuIHN0YXRzOw0KKwl9DQorDQorCWZvciAoaT0wOyBpIDwgTlJfQ1BVUzsg aSsrKSB7DQorCQlpZiAoIWNwdV9wb3NzaWJsZShpKSkgDQorCQkJY29udGlu dWU7DQorCQlzdGF0cy0+cnhfYnl0ZXMgICArPSBwZXJfY3B1X3B0cihsb29w YmFja19zdGF0cywgaSktPnJ4X2J5dGVzOw0KKwkJc3RhdHMtPnR4X2J5dGVz ICAgKz0gcGVyX2NwdV9wdHIobG9vcGJhY2tfc3RhdHMsIGkpLT50eF9ieXRl czsNCisJCXN0YXRzLT5yeF9wYWNrZXRzICs9IHBlcl9jcHVfcHRyKGxvb3Bi YWNrX3N0YXRzLCBpKS0+cnhfcGFja2V0czsNCisJCXN0YXRzLT50eF9wYWNr ZXRzICs9IHBlcl9jcHVfcHRyKGxvb3BiYWNrX3N0YXRzLCBpKS0+dHhfcGFj a2V0czsNCisJfQ0KKwkJCQkNCisJcmV0dXJuIHN0YXRzOw0KIH0NCiANCiBz dHJ1Y3QgbmV0X2RldmljZSBsb29wYmFja19kZXYgPSB7DQpAQCAtMTczLDcg KzE5OSw4IEBADQogCS5yZWJ1aWxkX2hlYWRlcgkJPSBldGhfcmVidWlsZF9o ZWFkZXIsDQogCS5mbGFncwkJCT0gSUZGX0xPT1BCQUNLLA0KIAkuZmVhdHVy ZXMgCQk9IE5FVElGX0ZfU0d8TkVUSUZfRl9GUkFHTElTVA0KLQkJCQkgIHxO RVRJRl9GX05PX0NTVU18TkVUSUZfRl9ISUdIRE1BLA0KKwkJCQkgIHxORVRJ Rl9GX05PX0NTVU18TkVUSUZfRl9ISUdIRE1BDQorCQkJCSAgfE5FVElGX0Zf TExUWCwNCiB9Ow0KIA0KIC8qIFNldHVwIGFuZCByZWdpc3RlciB0aGUgb2Yg dGhlIExPT1BCQUNLIGRldmljZS4gKi8NCkBAIC0xODgsNiArMjE1LDggQEAN CiAJCWxvb3BiYWNrX2Rldi5wcml2ID0gc3RhdHM7DQogCQlsb29wYmFja19k ZXYuZ2V0X3N0YXRzID0gJmdldF9zdGF0czsNCiAJfQ0KKw0KKwlsb29wYmFj a19zdGF0cyA9IGFsbG9jX3BlcmNwdShzdHJ1Y3QgbmV0X2RldmljZV9zdGF0 cyk7DQogCQ0KIAlyZXR1cm4gcmVnaXN0ZXJfbmV0ZGV2KCZsb29wYmFja19k ZXYpOw0KIH07DQotLS0gbGludXgub3JpZy8vaW5jbHVkZS9saW51eC9uZXRk ZXZpY2UuaAkyMDA0LTA2LTA4IDE1OjM2OjUxLjAwMDAwMDAwMCAtMDcwMA0K KysrIGxpbnV4Ly9pbmNsdWRlL2xpbnV4L25ldGRldmljZS5oCTIwMDQtMDYt MTQgMDk6MjA6MjYuMDAwMDAwMDAwIC0wNzAwDQpAQCAtNDAzLDYgKzQwMyw3 IEBADQogI2RlZmluZSBORVRJRl9GX0hXX1ZMQU5fRklMVEVSCTUxMgkvKiBS ZWNlaXZlIGZpbHRlcmluZyBvbiBWTEFOICovDQogI2RlZmluZSBORVRJRl9G X1ZMQU5fQ0hBTExFTkdFRAkxMDI0CS8qIERldmljZSBjYW5ub3QgaGFuZGxl IFZMQU4gcGFja2V0cyAqLw0KICNkZWZpbmUgTkVUSUZfRl9UU08JCTIwNDgJ LyogQ2FuIG9mZmxvYWQgVENQL0lQIHNlZ21lbnRhdGlvbiAqLw0KKyNkZWZp bmUgTkVUSUZfRl9MTFRYCQk0MDk2CS8qIExvY2tMZXNzIFRYICovDQogDQog CS8qIENhbGxlZCBhZnRlciBkZXZpY2UgaXMgZGV0YWNoZWQgZnJvbSBuZXR3 b3JrLiAqLw0KIAl2b2lkCQkJKCp1bmluaXQpKHN0cnVjdCBuZXRfZGV2aWNl ICpkZXYpOw0KLS0tIGxpbnV4Lm9yaWcvL2luY2x1ZGUvbmV0L3BrdF9zY2hl ZC5oCTIwMDQtMDYtMDggMTU6MzY6NTEuMDAwMDAwMDAwIC0wNzAwDQorKysg bGludXgvL2luY2x1ZGUvbmV0L3BrdF9zY2hlZC5oCTIwMDQtMDYtMTEgMTM6 NDY6MjUuMDAwMDAwMDAwIC0wNzAwDQpAQCAtMTEsNiArMTEsNyBAQA0KICNp bmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4NCiAjaW5jbHVkZSA8bGludXgv dHlwZXMuaD4NCiAjaW5jbHVkZSA8bGludXgvcGt0X3NjaGVkLmg+DQorI2lu Y2x1ZGUgPGxpbnV4L3JjdXBkYXRlLmg+DQogI2luY2x1ZGUgPG5ldC9wa3Rf Y2xzLmg+DQogDQogI2lmZGVmIENPTkZJR19YODZfVFNDDQpAQCAtOTIsNiAr OTMsNyBAQA0KIAlzdHJ1Y3QgbmV0X2RldmljZQkqZGV2Ow0KIA0KIAlzdHJ1 Y3QgdGNfc3RhdHMJCXN0YXRzOw0KKwlzdHJ1Y3QgcmN1X2hlYWQgCXFfcmN1 Ow0KIAlpbnQJCQkoKnJlc2hhcGVfZmFpbCkoc3RydWN0IHNrX2J1ZmYgKnNr Yiwgc3RydWN0IFFkaXNjICpxKTsNCiANCiAJLyogVGhpcyBmaWVsZCBpcyBk ZXByZWNhdGVkLCBidXQgaXQgaXMgc3RpbGwgdXNlZCBieSBDQlENCi0tLSBs aW51eC5vcmlnLy9uZXQvY29yZS9kZXYuYwkyMDA0LTA2LTA4IDE1OjM2OjUz LjAwMDAwMDAwMCAtMDcwMA0KKysrIGxpbnV4Ly9uZXQvY29yZS9kZXYuYwky MDA0LTA2LTE0IDA5OjI2OjE4LjAwMDAwMDAwMCAtMDcwMA0KQEAgLTEwNyw2 ICsxMDcsNyBAQA0KICNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4NCiAjaW5j bHVkZSA8bGludXgva2FsbHN5bXMuaD4NCiAjaW5jbHVkZSA8bGludXgvbmV0 cG9sbC5oPg0KKyNpbmNsdWRlIDxsaW51eC9yY3VwZGF0ZS5oPg0KICNpZmRl ZiBDT05GSUdfTkVUX1JBRElPDQogI2luY2x1ZGUgPGxpbnV4L3dpcmVsZXNz Lmg+CQkvKiBOb3RlIDogd2lsbCBkZWZpbmUgV0lSRUxFU1NfRVhUICovDQog I2luY2x1ZGUgPG5ldC9pd19oYW5kbGVyLmg+DQpAQCAtMTI3Nyw2ICsxMjc4 LDIwIEBADQogCXJldHVybiAwOw0KIH0NCiANCisjZGVmaW5lIEhBUkRfVFhf TE9DS19CSChkZXYsIGNwdSkgewkJCVwNCisJaWYgKCBkZXYtPmZlYXR1cmVz ICYmIE5FVElGX0ZfTExUWCAgPT0gMCApIHsJXA0KKwkJc3Bpbl9sb2NrX2Jo KCZkZXYtPnhtaXRfbG9jayk7CQlcDQorCQlkZXYtPnhtaXRfbG9ja19vd25l ciA9IGNwdTsJCVwNCisJfQkJCQkJCVwNCit9DQorDQorI2RlZmluZSBIQVJE X1RYX1VOTE9DS19CSChkZXYpIHsJCQlcDQorCWlmICggZGV2LT5mZWF0dXJl cyAmJiBORVRJRl9GX0xMVFggID09IDAgKSB7CVwNCisJCWRldi0+eG1pdF9s b2NrX293bmVyID0gLTE7CQlcDQorCQlzcGluX3VubG9ja19iaCgmZGV2LT54 bWl0X2xvY2spOwlcDQorCX0JCQkJCQlcDQorfQ0KKw0KIC8qKg0KICAqCWRl dl9xdWV1ZV94bWl0IC0gdHJhbnNtaXQgYSBidWZmZXINCiAgKglAc2tiOiBi dWZmZXIgdG8gdHJhbnNtaXQNCkBAIC0xMzIxLDE4ICsxMzM2LDM0IEBADQog CQkJZ290byBvdXQ7DQogCX0NCiANCi0JLyogR3JhYiBkZXZpY2UgcXVldWUg Ki8NCi0Jc3Bpbl9sb2NrX2JoKCZkZXYtPnF1ZXVlX2xvY2spOw0KKwlyY3Vf cmVhZF9sb2NrKCk7DQorCS8qIFVwZGF0ZXMgb2YgcWRpc2MgYXJlIHNlcmlh bGl6ZWQgYnkgcXVldWVfbG9jay4gDQorCSAqIFRoZSBzdHJ1Y3QgUWRpc2Mg d2hpY2ggaXMgcG9pbnRlZCB0byBieSBxZGlzYyBpcyBub3cgYSANCisJICog cmN1IHN0cnVjdHVyZSAtIGl0IG1heSBiZSBhY2Nlc3NlZCB3aXRob3V0IGFj cXVpcmluZyANCisJICogYSBsb2NrIChidXQgdGhlIHN0cnVjdHVyZSBtYXkg YmUgc3RhbGUuKSBUaGUgZnJlZWluZyBvZiB0aGUNCisJICogcWRpc2Mgd2ls bCBiZSBkZWZlcnJlZCB1bnRpbCBpdCdzIGtub3duIHRoYXQgdGhlcmUgYXJl IG5vIA0KKwkgKiBtb3JlIHJlZmVyZW5jZXMgdG8gaXQuDQorCSAqIA0KKwkg KiBJZiB0aGUgcWRpc2MgaGFzIGFuIGVucXVldWUgZnVuY3Rpb24sIHdlIHN0 aWxsIG5lZWQgdG8gDQorCSAqIGhvbGQgdGhlIHF1ZXVlX2xvY2sgYmVmb3Jl IGNhbGxpbmcgaXQsIHNpbmNlIHF1ZXVlX2xvY2sNCisJICogYWxzbyBzZXJp YWxpemVzIGFjY2VzcyB0byB0aGUgZGV2aWNlIHF1ZXVlLg0KKwkgKi8NCisN CiAJcSA9IGRldi0+cWRpc2M7DQogCWlmIChxLT5lbnF1ZXVlKSB7DQorCQkv KiBHcmFiIGRldmljZSBxdWV1ZSAqLw0KKwkJc3Bpbl9sb2NrX2JoKCZkZXYt PnF1ZXVlX2xvY2spOw0KKw0KIAkJcmMgPSBxLT5lbnF1ZXVlKHNrYiwgcSk7 DQogDQogCQlxZGlzY19ydW4oZGV2KTsNCiANCiAJCXNwaW5fdW5sb2NrX2Jo KCZkZXYtPnF1ZXVlX2xvY2spOw0KKwkJcmN1X3JlYWRfdW5sb2NrKCk7DQog CQlyYyA9IHJjID09IE5FVF9YTUlUX0JZUEFTUyA/IE5FVF9YTUlUX1NVQ0NF U1MgOiByYzsNCiAJCWdvdG8gb3V0Ow0KIAl9DQorCXJjdV9yZWFkX3VubG9j aygpOw0KIA0KIAkvKiBUaGUgZGV2aWNlIGhhcyBubyBxdWV1ZS4gQ29tbW9u IGNhc2UgZm9yIHNvZnR3YXJlIGRldmljZXM6DQogCSAgIGxvb3BiYWNrLCBh bGwgdGhlIHNvcnRzIG9mIHR1bm5lbHMuLi4NCkBAIC0xMzQ3LDE3ICsxMzc4 LDEyIEBADQogCSAgIEVpdGhlciBzaG90IG5vcXVldWUgcWRpc2MsIGl0IGlz IGV2ZW4gc2ltcGxlciA4KQ0KIAkgKi8NCiAJaWYgKGRldi0+ZmxhZ3MgJiBJ RkZfVVApIHsNCisJCXByZWVtcHRfZGlzYWJsZSgpOw0KIAkJaW50IGNwdSA9 IHNtcF9wcm9jZXNzb3JfaWQoKTsNCiANCiAJCWlmIChkZXYtPnhtaXRfbG9j a19vd25lciAhPSBjcHUpIHsNCi0JCQkvKg0KLQkJCSAqIFRoZSBzcGluX2xv Y2sgZWZmZWN0aXZseSBkb2VzIGEgcHJlZW1wdCBsb2NrLCBidXQgDQotCQkJ ICogd2UgYXJlIGFib3V0IHRvIGRyb3AgdGhhdC4uLg0KLQkJCSAqLw0KLQkJ CXByZWVtcHRfZGlzYWJsZSgpOw0KLQkJCXNwaW5fdW5sb2NrKCZkZXYtPnF1 ZXVlX2xvY2spOw0KLQkJCXNwaW5fbG9jaygmZGV2LT54bWl0X2xvY2spOw0K LQkJCWRldi0+eG1pdF9sb2NrX293bmVyID0gY3B1Ow0KKw0KKwkJCUhBUkRf VFhfTE9DS19CSChkZXYsIGNwdSk7DQogCQkJcHJlZW1wdF9lbmFibGUoKTsN CiANCiAJCQlpZiAoIW5ldGlmX3F1ZXVlX3N0b3BwZWQoZGV2KSkgew0KQEAg LTEzNjYsMTggKzEzOTIsMTcgQEANCiANCiAJCQkJcmMgPSAwOw0KIAkJCQlp ZiAoIWRldi0+aGFyZF9zdGFydF94bWl0KHNrYiwgZGV2KSkgew0KLQkJCQkJ ZGV2LT54bWl0X2xvY2tfb3duZXIgPSAtMTsNCi0JCQkJCXNwaW5fdW5sb2Nr X2JoKCZkZXYtPnhtaXRfbG9jayk7DQorCQkJCQlIQVJEX1RYX1VOTE9DS19C SChkZXYpOw0KIAkJCQkJZ290byBvdXQ7DQogCQkJCX0NCiAJCQl9DQotCQkJ ZGV2LT54bWl0X2xvY2tfb3duZXIgPSAtMTsNCi0JCQlzcGluX3VubG9ja19i aCgmZGV2LT54bWl0X2xvY2spOw0KKwkJCUhBUkRfVFhfVU5MT0NLX0JIKGRl dik7DQogCQkJaWYgKG5ldF9yYXRlbGltaXQoKSkNCiAJCQkJcHJpbnRrKEtF Uk5fQ1JJVCAiVmlydHVhbCBkZXZpY2UgJXMgYXNrcyB0byAiDQogCQkJCSAg ICAgICAicXVldWUgcGFja2V0IVxuIiwgZGV2LT5uYW1lKTsNCiAJCQlnb3Rv IG91dF9lbmV0ZG93bjsNCiAJCX0gZWxzZSB7DQorCQkJcHJlZW1wdF9lbmFi bGUoKTsNCiAJCQkvKiBSZWN1cnNpb24gaXMgZGV0ZWN0ZWQhIEl0IGlzIHBv c3NpYmxlLA0KIAkJCSAqIHVuZm9ydHVuYXRlbHkgKi8NCiAJCQlpZiAobmV0 X3JhdGVsaW1pdCgpKQ0KQEAgLTEzODUsNyArMTQxMCw2IEBADQogCQkJCSAg ICAgICAiJXMsIGZpeCBpdCB1cmdlbnRseSFcbiIsIGRldi0+bmFtZSk7DQog CQl9DQogCX0NCi0Jc3Bpbl91bmxvY2tfYmgoJmRldi0+cXVldWVfbG9jayk7 DQogb3V0X2VuZXRkb3duOg0KIAlyYyA9IC1FTkVURE9XTjsNCiBvdXRfa2Zy ZWVfc2tiOg0KLS0tIGxpbnV4Lm9yaWcvL25ldC9zY2hlZC9zY2hfZ2VuZXJp Yy5jCTIwMDQtMDYtMDggMTU6MzY6NTMuMDAwMDAwMDAwIC0wNzAwDQorKysg bGludXgvL25ldC9zY2hlZC9zY2hfZ2VuZXJpYy5jCTIwMDQtMDYtMTEgMTM6 NTI6MDYuMDAwMDAwMDAwIC0wNzAwDQpAQCAtMzAsNiArMzAsNyBAQA0KICNp bmNsdWRlIDxsaW51eC9za2J1ZmYuaD4NCiAjaW5jbHVkZSA8bGludXgvcnRu ZXRsaW5rLmg+DQogI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4NCisjaW5jbHVk ZSA8bGludXgvcmN1cGRhdGUuaD4NCiAjaW5jbHVkZSA8bmV0L3NvY2suaD4N CiAjaW5jbHVkZSA8bmV0L3BrdF9zY2hlZC5oPg0KIA0KQEAgLTQwNCwxOCAr NDA1LDM2IEBADQogCQlvcHMtPnJlc2V0KHFkaXNjKTsNCiB9DQogDQorLyog dGhpcyBpcyB0aGUgcmN1IGNhbGxiYWNrIGZ1bmN0aW9uIHRvIGNsZWFuIHVw IGEgcWRpc2Mgd2hlbiB0aGVyZSANCisgKiBhcmUgbm8gZnVydGhlciByZWZl cmVuY2VzIHRvIGl0ICovDQorDQorc3RhdGljIHZvaWQgX19xZGlzY19kZXN0 cm95ICh2b2lkICogYXJnKSANCit7DQorCXN0cnVjdCBRZGlzYyAgICAqcWRp c2MgPSAoc3RydWN0IFFkaXNjICopIGFyZzsNCisJc3RydWN0IFFkaXNjX29w cyAgKm9wcyA9IHFkaXNjLT5vcHM7DQorDQorI2lmZGVmIENPTkZJR19ORVRf RVNUSU1BVE9SDQorCXFkaXNjX2tpbGxfZXN0aW1hdG9yKCZxZGlzYy0+c3Rh dHMpOw0KKyNlbmRpZg0KKwlpZiAob3BzLT5yZXNldCkNCisJCW9wcy0+cmVz ZXQocWRpc2MpOw0KKwlpZiAob3BzLT5kZXN0cm95KQ0KKwkJb3BzLT5kZXN0 cm95KHFkaXNjKTsNCisJbW9kdWxlX3B1dChvcHMtPm93bmVyKTsNCisNCisJ aWYgKCEocWRpc2MtPmZsYWdzJlRDUV9GX0JVSUxUSU4pKQ0KKwkJa2ZyZWUo cWRpc2MpOw0KK30NCisNCiAvKiBVbmRlciBkZXYtPnF1ZXVlX2xvY2sgYW5k IEJIISAqLw0KIA0KIHZvaWQgcWRpc2NfZGVzdHJveShzdHJ1Y3QgUWRpc2Mg KnFkaXNjKQ0KIHsNCi0Jc3RydWN0IFFkaXNjX29wcyAqb3BzID0gcWRpc2Mt Pm9wczsNCi0Jc3RydWN0IG5ldF9kZXZpY2UgKmRldjsNCisJc3RydWN0IG5l dF9kZXZpY2UgKmRldiA9IHFkaXNjLT5kZXY7DQogDQogCWlmICghYXRvbWlj X2RlY19hbmRfdGVzdCgmcWRpc2MtPnJlZmNudCkpDQogCQlyZXR1cm47DQog DQotCWRldiA9IHFkaXNjLT5kZXY7DQotDQogCWlmIChkZXYpIHsNCiAJCXN0 cnVjdCBRZGlzYyAqcSwgKipxcDsNCiAJCWZvciAocXAgPSAmcWRpc2MtPmRl di0+cWRpc2NfbGlzdDsgKHE9KnFwKSAhPSBOVUxMOyBxcCA9ICZxLT5uZXh0 KSB7DQpAQCAtNDI1LDE2ICs0NDQsOSBAQA0KIAkJCX0NCiAJCX0NCiAJfQ0K LSNpZmRlZiBDT05GSUdfTkVUX0VTVElNQVRPUg0KLQlxZGlzY19raWxsX2Vz dGltYXRvcigmcWRpc2MtPnN0YXRzKTsNCi0jZW5kaWYNCi0JaWYgKG9wcy0+ cmVzZXQpDQotCQlvcHMtPnJlc2V0KHFkaXNjKTsNCi0JaWYgKG9wcy0+ZGVz dHJveSkNCi0JCW9wcy0+ZGVzdHJveShxZGlzYyk7DQotCW1vZHVsZV9wdXQo b3BzLT5vd25lcik7DQotCWlmICghKHFkaXNjLT5mbGFncyZUQ1FfRl9CVUlM VElOKSkNCi0JCWtmcmVlKHFkaXNjKTsNCisNCisJY2FsbF9yY3UoJnFkaXNj LT5xX3JjdSwgX19xZGlzY19kZXN0cm95LCBxZGlzYyk7DQorDQogfQ0KIA0K IA0K ---1072017398-1816748115-1087232632=:479900-- From jgarzik@pobox.com Mon Jun 14 10:52:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 10:52:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EHqogi018419 for ; Mon, 14 Jun 2004 10:52:51 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BZvdZ-00061l-38; Mon, 14 Jun 2004 18:52:49 +0100 Message-ID: <40CDE5E3.7060009@pobox.com> Date: Mon, 14 Jun 2004 13:52:35 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] fix oops from acenic ethtool References: <20040604145333.34d1600f@dell_ss3.pdx.osdl.net> <40C9022F.8050102@pobox.com> <20040614094034.7f06445c@dell_ss3.pdx.osdl.net> In-Reply-To: <20040614094034.7f06445c@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5913 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: 447 Lines: 15 Stephen Hemminger wrote: > Here is a revised version of the acenic patch: > * use ethtool_ops - solves OOPS on boot up > * put firmware and driver version in correct place in ethtool info response > * get rid of #ifdef SIOCETHTOOL > > Signed-off-by: Stephen Hemminger I apologize... as per my most recent comment to you, I merged your earlier patch and fixed the ifdef myself. Latest should be in -mm tree. Jeff From mitch@sfgoth.com Mon Jun 14 11:19:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 11:19:38 -0700 (PDT) Received: from gaz.sfgoth.com (gaz.sfgoth.com [69.36.241.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EIJWgi019220 for ; Mon, 14 Jun 2004 11:19:33 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.10/8.12.9) with ESMTP id i5EINbIp040213; Mon, 14 Jun 2004 11:23:37 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.10/8.12.6/Submit) id i5EINbIH040212; Mon, 14 Jun 2004 11:23:37 -0700 (PDT) (envelope-from mitch) Date: Mon, 14 Jun 2004 11:23:36 -0700 From: Mitchell Blank Jr To: Arthur Kepner Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] lockless loopback patch for 2.6 (version 2) Message-ID: <20040614182336.GC11280@gaz.sfgoth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 5914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Content-Length: 366 Lines: 14 Arthur Kepner wrote: > +#define HARD_TX_LOCK_BH(dev, cpu) { \ > + if ( dev->features && NETIF_F_LLTX == 0 ) { \ ^^ Don't you mean '&' instead of '&&' here? It looks like that condition is always false, so you've killed the TX locking for all devices with this patch. > + if ( dev->features && NETIF_F_LLTX == 0 ) { \ ditto -Mitch From ak@suse.de Mon Jun 14 11:23:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 11:23:44 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EINbgi019590 for ; Mon, 14 Jun 2004 11:23: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 C08D86F46BA; Mon, 14 Jun 2004 20:23:31 +0200 (CEST) Date: Mon, 14 Jun 2004 20:23:31 +0200 From: Andi Kleen To: Arthur Kepner Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] lockless loopback patch for 2.6 (version 2) Message-ID: <20040614182331.GA11862@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5915 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: 1630 Lines: 63 > +#define LOOPBACK_STAT_INC(field) \ > + (per_cpu_ptr(loopback_stats, smp_processor_id())->field++) > +#define LOOPBACK_STAT_ADD(field, n) \ > + (per_cpu_ptr(loopback_stats, smp_processor_id())->field += n) This is too complicated and not preempt safe. Use __get_cpu_var(loopback_stats).field++; I would also remove the macros and do this directly. > + struct net_device_stats *stats = dev->priv; > + int i; > + > + if (unlikely(!stats)) { Tests for NULL don't need an unlikely, because gcc does that by default for itself. But why can the stats here be NULL anyways? > #ifdef CONFIG_NET_RADIO > #include /* Note : will define WIRELESS_EXT */ > #include > @@ -1277,6 +1278,20 @@ > return 0; > } > > +#define HARD_TX_LOCK_BH(dev, cpu) { \ > + if ( dev->features && NETIF_F_LLTX == 0 ) { \ && instead of & and missing brackets. > + spin_lock_bh(&dev->xmit_lock); \ > + dev->xmit_lock_owner = cpu; \ > + } \ > +} > + > +#define HARD_TX_UNLOCK_BH(dev) { \ > + if ( dev->features && NETIF_F_LLTX == 0 ) { \ Same. > - if (ops->reset) > - ops->reset(qdisc); > - if (ops->destroy) > - ops->destroy(qdisc); > - module_put(ops->owner); > - if (!(qdisc->flags&TCQ_F_BUILTIN)) > - kfree(qdisc); > + > + call_rcu(&qdisc->q_rcu, __qdisc_destroy, qdisc); I think you need at least a wmb() after if (q == qdisc) { *qp = q->next; break; } Otherwise the order of updates to the readers is no guaranteed. Also if you want to support alpha there will need to be smp_read_barrier_depends() in the reader walking this list. -Andi From rl@hellgate.ch Mon Jun 14 12:05:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 12:05:38 -0700 (PDT) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EJ5Zgi020512 for ; Mon, 14 Jun 2004 12:05:35 -0700 Received: from k3.hellgate.ch (62.203.176.143) by mail2.bluewin.ch (Bluewin AG 7.0.028) id 40A46896003B12D9; Mon, 14 Jun 2004 10:03:28 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 6EB639124A5; Mon, 14 Jun 2004 12:03:26 +0200 (CEST) Date: Mon, 14 Jun 2004 12:03:26 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Restructure reset code Message-ID: <20040614100326.GA32763@k3.hellgate.ch> References: <20040602115920.GA17634@k3.hellgate.ch> <40BE2DE0.4040102@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BE2DE0.4040102@pobox.com> X-Operating-System: Linux 2.6.7-rc1 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 664 Lines: 18 On Wed, 02 Jun 2004 15:43:28 -0400, Jeff Garzik wrote: > Roger Luethi wrote: > >Restructure code to make it easier to maintain. [...] > Rejected, two reasons: > > 1) dev->dev_addr[] should be loaded from eeprom only once, at probe > time, not once for each hw init. [this value should be written to the > chip's MAC address registers upon each dev->open() call] > > 2) Your "Note:" worries me... why not deal with this now? :) I addressed your concerns in my June 2 reply, but the patch didn't get merged. Meanwhile, I am maintaining a growing queue of via-rhine patches that need review and wider testing -- what is missing to move forward in -mm? Roger From marc.herbert@free.fr Mon Jun 14 12:36:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 12:36:40 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EJaEgi024397 for ; Mon, 14 Jun 2004 12:36:15 -0700 Received: from mutualite-3-82-67-66-29.fbx.proxad.net (mutualite-3-82-67-66-29.fbx.proxad.net [82.67.66.29]) by postfix4-1.free.fr (Postfix) with ESMTP id BB457142EEE; Mon, 14 Jun 2004 21:32:07 +0200 (CEST) Date: Mon, 14 Jun 2004 21:32:42 +0200 (CEST) From: Marc Herbert X-X-Sender: mherbert@fcat To: Tim Hockin Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics In-Reply-To: <20040614170138.GA32594@hockin.org> Message-ID: References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> <40C77C70.5070409@tmr.com> <20040609213850.GA17243@k3.hellgate.ch> <20040609151246.1c28c4d9.davem@redhat.com> <20040614170138.GA32594@hockin.org> 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 i5EJaEgi024397 X-archive-position: 5917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc.herbert@free.fr Precedence: bulk X-list: netdev Content-Length: 2502 Lines: 67 On Mon, 14 Jun 2004, Tim Hockin wrote: > > This is precisely the reason why I am concerned about having "rich" > > ethtool semantics. A unified, standard interface is great,... as long > > it does not leave behind some features, like setting the advertised > > values in autoneg. As a user of these features, I hope driver > > developers will NOT remove those module_param features that cannot > > migrated to ethtool. > > So propose a sane semantic that handles all three cases: > * autoneg on > * autoneg off > * autoneg on but limited Looking at the examples I mentioned earlier in the thread, one can draw the following two simple solutions: 1. "Max speed advertised" solution autoneg | on off speed | --------------|----------------------------- | | advertise all force 10 10 | adv. 10 force 10 100 | adv. 10|100 frc. 100 1000 | adv. 10|100|1000 frc. 1000 2."Fixed speed advertised" solution autoneg | on off speed | --------------|----------------------------- | | advertise all force 10 10 | adv. 10 force 10 100 | adv. 100 frc. 100 1000 | adv. 1000 frc. 1000 You can easily figure out similar and shorter tables for half/full duplex (considering that duplex > half). A 3rd solution which kind of avoids the dilemma between 1. and 2. is to give the user full control on advertised bits, as does (did?) the e1000 driver and its "AutoNeg" module_param. This third solution is often less user friendly and probably not very useful. And it would require a new argument to ethtool, whereas the first two solutions do not. If given the choice, I would vote for solution 1., but it probably does not make much difference with solution number 2 in practice. Auto negociation of flow control is unfortunately more complex, as you can see in this discussion with Rich Seifert in comp.dcom.lans.ethernet for those interested http://groups.google.com/groups?threadm=87hdvnd0x3.fsf%40free.fr But I believe flow control issues do not have any influence on the above, so... first things first: no need to dive into this at this point. Obviously this message ignores legacy code, hardware bugs and others "small matters of implementation". I suspect Roger Luethi has both a knowledge of the related code and an opinion on this issue. From akepner@sgi.com Mon Jun 14 12:50:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 12:50:36 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EJoYgi024944 for ; Mon, 14 Jun 2004 12:50:34 -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 i5EJwZ1Y001258 for ; Mon, 14 Jun 2004 12:58:35 -0700 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i5EJoDl716804408; Mon, 14 Jun 2004 12:50:29 -0700 (PDT) Date: Mon, 14 Jun 2004 12:45:25 -0700 From: Arthur Kepner X-X-Sender: akepner@neteng.engr.sgi.com To: Mitchell Blank Jr cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] lockless loopback patch for 2.6 (version 2) In-Reply-To: <20040614182336.GC11280@gaz.sfgoth.com> Message-ID: References: <20040614182336.GC11280@gaz.sfgoth.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5918 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: 448 Lines: 18 On Mon, 14 Jun 2004, Mitchell Blank Jr wrote: > Arthur Kepner wrote: > > +#define HARD_TX_LOCK_BH(dev, cpu) { \ > > + if ( dev->features && NETIF_F_LLTX == 0 ) { \ > ^^ > > Don't you mean '&' instead of '&&' here? It looks like that condition is > always false, so you've killed the TX locking for all devices with this > patch. Ummm, yes. (I believe the appropriate response here is "D'oh!") Thanks. -- Arthur From mcgrof@studorgs.rutgers.edu Mon Jun 14 12:57:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 12:57:33 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EJvJgi025331 for ; Mon, 14 Jun 2004 12:57:19 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 391AEF98B1; Mon, 14 Jun 2004 15:16:51 -0400 (EDT) Date: Mon, 14 Jun 2004 15:16:51 -0400 To: Jeff Garzik Cc: Netdev , prism54-devel@prism54.org Subject: [Prism54] CVS -> bk tree update Message-ID: <20040614191651.GC6253@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , Netdev , prism54-devel@prism54.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" 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: 5919 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: 702 Lines: 33 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Jeff, was wondering what the status of the latest prism54 patches is. Did all go through cleanly, are we in-sync now? Are there patches you're still reviewing? Thanks, Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAzfmjat1JN+IKUl4RAnLMAJ0Yo3KXphresWxCUiqQbI3c8qdndQCgil5f LSKjIDAy09wbCqw3WvhkLbQ= =nzlM -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From vkondra@mail.ru Mon Jun 14 13:55:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 13:55:14 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EKt7gi026575 for ; Mon, 14 Jun 2004 13:55:08 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 5F303DE908 for ; Tue, 15 Jun 2004 00:54:51 +0400 (MSD) Received: from [81.218.116.94] (port=55563 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BZySg-0006Bq-00; Tue, 15 Jun 2004 00:53:48 +0400 From: Vladimir Kondratiev To: hadi@cyberus.ca Subject: Re: in-driver QoS Date: Mon, 14 Jun 2004 23:53:26 +0300 User-Agent: KMail/1.6.2 References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406111619.40260.vkondra@mail.ru> <1086960639.1068.697.camel@jzny.localdomain> In-Reply-To: <1086960639.1068.697.camel@jzny.localdomain> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406142353.28277.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 5920 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: 1241 Lines: 30 Jamal, let's list the features need to be provided for 802.11 QoS, and problems. It is worth to provide standard interface with wireless stack; otherwise each driver will invent its own solution. 1. NIC have number of Tx DMA channels, with different channels used for different priorities. It is dictated by standard (TGe). Most likely, it should be 4 queues for EDCA traffic (4 priorities), 1 for HCCA (polled, pre-agreed streams) and optionally 1 for multicast traffic (AP need it). Each queue need to start/stop separately. For flexibility, it should be some way for driver to request queues and specify mapping to these queues. Ideas for how to implement it in stack? Meanwhile, ideas how to get separate per-priority control with existing infrastructure? 2. There is traffic that require admission control. Unless driver performs allocation with AP, this traffic is not allowed. TGe standard dictates it. Driver should participate in bandwidth allocation (via RSVP?). It should get some form of request (IOCTL?) which it will serve by performing allocation on link layer. It is easy to do proprietary IOCTL and white custom RSVP daemon, but it is much better to do something generic for all drivers to use. Vladimir. From rl@hellgate.ch Mon Jun 14 14:16:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 14:16:30 -0700 (PDT) Received: from mail5.bluewin.ch (mail5.bluewin.ch [195.186.1.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ELGOgi027331 for ; Mon, 14 Jun 2004 14:16:24 -0700 Received: from k3.hellgate.ch (62.203.92.118) by mail5.bluewin.ch (Bluewin AG 7.0.028) id 40A46B21003E66A2; Mon, 14 Jun 2004 19:43:01 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 917C7918CB3; Mon, 14 Jun 2004 21:42:56 +0200 (CEST) Date: Mon, 14 Jun 2004 21:42:56 +0200 From: Roger Luethi To: Tim Hockin Cc: Marc Herbert , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] ethtool semantics Message-ID: <20040614194256.GC22012@k3.hellgate.ch> Mail-Followup-To: Tim Hockin , Marc Herbert , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20040607212804.GA17012@k3.hellgate.ch> <20040607145723.41da5783.davem@redhat.com> <20040608210809.GA10542@k3.hellgate.ch> <40C77C70.5070409@tmr.com> <20040609213850.GA17243@k3.hellgate.ch> <20040609151246.1c28c4d9.davem@redhat.com> <20040614170138.GA32594@hockin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040614170138.GA32594@hockin.org> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1782 Lines: 39 On Mon, 14 Jun 2004 10:01:38 -0700, Tim Hockin wrote: > On Mon, Jun 14, 2004 at 03:11:15PM +0200, Marc Herbert wrote: > > > That is absolutely the correct thing to do, module parameters for > > > link settings are %100 deprecated, people need to use ethtool for > > > everything. > > > > This is precisely the reason why I am concerned about having "rich" > > ethtool semantics. A unified, standard interface is great,... as long > > it does not leave behind some features, like setting the advertised > > values in autoneg. As a user of these features, I hope driver > > developers will NOT remove those module_param features that cannot > > migrated to ethtool. > > So propose a sane semantic that handles all three cases: > * autoneg on > * autoneg off > * autoneg on but limited My first thought was if a command contains speed/duplex settings and autoneg is on, manipulate advertised value; if autoneg is off, force mode. That's not possible due to the way ethtool interacts with the kernel: It doesn't request a change in a specific field. Instead, ethtool reads all fields, flips the values it wants to have changed, then issues a set request for everything (speed, duplex, autoneg, etc.). In other words: speed/duplex fields are set for every call. One way out would be to have an explicit third option, say autoneg mask. That would give: autoneg on + speed/duplex -> error (only userspace/ethtool can do this!) autoneg off + speed/duplex -> force mode (driver) autoneg mask + speed/duplex -> change advertised value (driver) Many drivers would only support one of these two methods (force mode presumably), so we'd have to either throw an error if an unsupported method is requested, or print a notice and use the supported method to force the requested mode. Roger From brazilnut@us.ibm.com Mon Jun 14 15:05:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 15:05:52 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EM5igi028813 for ; Mon, 14 Jun 2004 15:05:50 -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.2) with ESMTP id i5EM5cwc423226 for ; Mon, 14 Jun 2004 18:05:38 -0400 Received: from localhost.localdomain (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5EM5bEV328390 for ; Mon, 14 Jun 2004 16:05:37 -0600 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5EM2bh19464 for netdev@oss.sgi.com; Mon, 14 Jun 2004 15:02:37 -0700 From: Don Fry Message-Id: <200406142202.i5EM2bh19464@localhost.localdomain> Subject: Ethernet MAC address question To: netdev@oss.sgi.com Date: Mon, 14 Jun 2004 15:02:36 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5922 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: 737 Lines: 19 When and/or why would an ethernet driver not use the MAC address from the PROM associated with the adapter? Since the MAC address can be specified via "ifconfig ethN ether ...." why not use the PROM value, and override it later if needed? I have received several complaints that the pcnet32 adapter is using the 'wrong' MAC address. By looking back through older kernels, the pcnet32 code was changed between November 2001 and February 2002 to read the MAC address from PROM, but to use whatever value was read from some volatile chip registers, which early chip versions do not even initialize. It seems to me the driver should always use the PROM address, assuming it has one. What am I missing? -- Don Fry brazilnut@us.ibm.com From jgarzik@pobox.com Mon Jun 14 15:32:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 15:32: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.12.10/8.12.9) with SMTP id i5EMW6gi029656 for ; Mon, 14 Jun 2004 15:32:07 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BZzzp-0002Hx-3W; Mon, 14 Jun 2004 23:32:05 +0100 Message-ID: <40CE2754.1020109@pobox.com> Date: Mon, 14 Jun 2004 18:31:48 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: Netdev , prism54-devel@prism54.org Subject: Re: [Prism54] CVS -> bk tree update References: <20040614191651.GC6253@ruslug.rutgers.edu> In-Reply-To: <20040614191651.GC6253@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5923 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: 272 Lines: 13 Luis R. Rodriguez wrote: > Hey Jeff, > > was wondering what the status of the latest prism54 patches is. Did all > go through cleanly, are we in-sync now? Are there patches you're still > reviewing? Check Andrew's -mm tree and see if there's anything missing. Jeff From jt@bougret.hpl.hp.com Mon Jun 14 15:51:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 15:51:03 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5EMoxgi030266 for ; Mon, 14 Jun 2004 15:50:59 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 75C7E1C181F6; Mon, 14 Jun 2004 15:50:59 -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 PAA22544; Mon, 14 Jun 2004 15:52:22 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Ba0I6-0003Kj-00; Mon, 14 Jun 2004 15:50:58 -0700 Date: Mon, 14 Jun 2004 15:50:58 -0700 To: "Andonieh, Joe" Cc: Jouni Malinen , netdev@oss.sgi.com Subject: Re: RFC: Linux wireless extensions and WPA support Message-ID: <20040614225058.GA3160@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <386CBF9421521B41835E2BF21BEF80B89B6211@hasmsx402.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <386CBF9421521B41835E2BF21BEF80B89B6211@hasmsx402.ger.corp.intel.com> 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: 5924 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: 1728 Lines: 49 On Mon, Jun 14, 2004 at 11:56:03AM +0300, Andonieh, Joe wrote: > > > Of course, we could change the IW_AUTH_ parameters for cipher and key > > Management suites to use bit field. This limits the number of options > to > > 32, but that should be enough and if not, can be extended in the > future. > > IW_AUTH_ALG_ is already doing this anyway and IW_AUTH_WPA_VERSION_ has > > Only two values, so it works as a bit field already (just needs to be > > Documented as such). > > I Guess this is a better approach to have it as a bit mask -- Maybe I s > till do not understand the interface correctly, but still I can't see > how the user can set the pairwise cipher separately from the group > cipher? The interface show > +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values */ > +#define IW_AUTH_CIPHER_NONE 0 > +#define IW_AUTH_CIPHER_WEP40 1 > +#define IW_AUTH_CIPHER_TKIP 2 > +#define IW_AUTH_CIPHER_CCMP 4 > +#define IW_AUTH_CIPHER_WEP104 5 > > But not specify which is what? You missed the other part of the API : +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/get to; value will be read/written to + * struct iw_param value field) */ +#define IW_AUTH_WPA_VERSION 0 +#define IW_AUTH_CIPHER_PAIRWISE 1 +#define IW_AUTH_CIPHER_GROUP 2 +#define IW_AUTH_KEY_MGMT 3 +#define IW_AUTH_TKIP_COUNTERMEASURES 4 +#define IW_AUTH_DROP_UNENCRYPTED 5 +#define IW_AUTH_80211_AUTH_ALG 6 If you combine both definitions, you get exactly what you want. Note that in this case, I'm with Jouni, I think a bitmask may be too limitative in the long run... > Thanks > Joe Have fun... Jean From jgarzik@pobox.com Mon Jun 14 16:35:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 16:35: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.12.10/8.12.9) with SMTP id i5ENZAgi002122 for ; Mon, 14 Jun 2004 16:35:11 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Ba0ym-0003E1-Lt; Tue, 15 Jun 2004 00:35:04 +0100 Message-ID: <40CE361A.9060707@pobox.com> Date: Mon, 14 Jun 2004 19:34:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: netdev@oss.sgi.com Subject: Re: Ethernet MAC address question References: <200406142202.i5EM2bh19464@localhost.localdomain> In-Reply-To: <200406142202.i5EM2bh19464@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5925 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: 990 Lines: 27 Don Fry wrote: > When and/or why would an ethernet driver not use the MAC address from > the PROM associated with the adapter? > > Since the MAC address can be specified via "ifconfig ethN ether ...." > why not use the PROM value, and override it later if needed? > > I have received several complaints that the pcnet32 adapter is using > the 'wrong' MAC address. By looking back through older kernels, the > pcnet32 code was changed between November 2001 and February 2002 to > read the MAC address from PROM, but to use whatever value was read > from some volatile chip registers, which early chip versions do not > even initialize. > > It seems to me the driver should always use the PROM address, assuming > it has one. What am I missing? In general, you are correct. However there are a few cases where some magic platform means loads the MAC address into the (volatile) MAC address registers, and that's the only source of an accurate MAC address for those people. Jeff From mcgrof@studorgs.rutgers.edu Mon Jun 14 21:17:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 21:17:48 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5F4Hcgi013434 for ; Mon, 14 Jun 2004 21:17:38 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id C4E4FF98B1; Tue, 15 Jun 2004 00:17:37 -0400 (EDT) Date: Tue, 15 Jun 2004 00:17:37 -0400 To: Jeff Garzik Cc: Don Fry , netdev@oss.sgi.com Subject: Re: Ethernet MAC address question Message-ID: <20040615041737.GF6253@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , Don Fry , netdev@oss.sgi.com References: <200406142202.i5EM2bh19464@localhost.localdomain> <40CE361A.9060707@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CE361A.9060707@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: 5926 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: 2684 Lines: 56 On Mon, Jun 14, 2004 at 07:34:50PM -0400, Jeff Garzik wrote: > Don Fry wrote: > >When and/or why would an ethernet driver not use the MAC address from > >the PROM associated with the adapter? > > > >Since the MAC address can be specified via "ifconfig ethN ether ...." > >why not use the PROM value, and override it later if needed? > > > >I have received several complaints that the pcnet32 adapter is using > >the 'wrong' MAC address. By looking back through older kernels, the > >pcnet32 code was changed between November 2001 and February 2002 to > >read the MAC address from PROM, but to use whatever value was read > >from some volatile chip registers, which early chip versions do not > >even initialize. > > > >It seems to me the driver should always use the PROM address, assuming > >it has one. What am I missing? > > In general, you are correct. > > However there are a few cases where some magic platform means loads the > MAC address into the (volatile) MAC address registers, and that's the > only source of an accurate MAC address for those people. > > Jeff In Prism54's case, since we need to first load a firmware to first obtain the MAC address, there's a time period where the default mac address is set to a temporary: 00:30:B4:00:00:00. This value was chosen by Jean (from HP). He sent in a patch to do this and added the following comment: /* Temporary dummy MAC address to use until firmware is loaded. * The idea there is that some tools (such as nameif) may query * the MAC address before the netdev is 'open'. By using a valid * OUI prefix, they can process the netdev properly. * Of course, this is not the final/real MAC address. It doesn't * matter, as you are suppose to be able to change it anytime via * ndev->set_mac_address. Jean II */ The real mac address will be populated currently if you modprobe prism54, the firmware is loaded as a result and then there is a netdev open (ifconfig eth0 up). There after the mac address is saved unless you rmmod the driver. PS. A bit off topic but I'll soon send in a patch for review about loading the firmware @ device probe Vs only at netdevice open time. This will allow the mac address to always be correctly populated if the firmware is present with the downside that you'll see a kernel message complaining it didn't find the firmware if it was not found (to try to reload the firmware all you would have to do is just try to bring the device up, so this is not an issue for a built-in). I'll also shut the radio off at probe though to not waste precious energy when on battery-powered laptops. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From ap@swapped.cc Mon Jun 14 21:56:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jun 2004 21:57:01 -0700 (PDT) Received: from mx.coredump.cc (S010600105aa5438e.vc.shawcable.net [24.87.213.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5F4uxgi015342 for ; Mon, 14 Jun 2004 21:56:59 -0700 Received: (qmail 28099 invoked from network); 15 Jun 2004 05:07:38 -0000 Received: from unknown (HELO swapped.cc) (10.0.0.104) by 10.0.0.1 with SMTP; 15 Jun 2004 05:07:38 -0000 Message-ID: <40CE818C.2090906@swapped.cc> Date: Mon, 14 Jun 2004 21:56:44 -0700 From: Alex Pankratov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 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 Subject: ENOBUFS and dev_queue_xmit() Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ap@swapped.cc Precedence: bulk X-list: netdev Content-Length: 1450 Lines: 43 I've been poking around rather weird problem today where send() on UDP socket was failing with ENETDOWN. When traced down to the kernel, it happened to originate in dev_queue_xmit() - if (!netif_queue_stopped(dev)) { ... } ... $here meaning that the device's queue was stopped. The comment there implies that only a broken virtual device may end up $here, but the fact is that I saw it for a physical interface running slightly modified via-rhine driver. The original driver code contains a snippet that stops the queue if its Tx ring buffer becomes full - if (np->cur_tx == np->dirty_tx + TX_QUEUE_LEN) netif_stop_queue(dev); and this code got actually executed with a hack applied. At this point I thought that dev_queue_xmit() must be mistakenly returning ENETDOWN instead of ENOBUFS, but looking at 'man 2 send' I saw that - ENOBUFS The output queue for a network interface was full...snip... (Normally, this does not occur in Linux. Packets are just silently dropped when a device queue overflows.) Hmmm... so I looked at e100 and tulip and these both stop the queue too if they run out of buffers. In other words, the 'silently dropped' clause from man page does not seem to be consistently followed. Is this a known (pseudo?) issue ? ENOBUFS makes much more sense in this context. I can certainly check interface status (IFF_UP) on every ENETDOWN to see what's the real cause, but that's kind of ugly. Alex From broonie@projectcolo.org.uk Tue Jun 15 02:58:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 02:59:03 -0700 (PDT) Received: from kerouac.projectcolo.org.uk (kerouac.projectcolo.org.uk [80.71.3.114]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5F9wIgi029667 for ; Tue, 15 Jun 2004 02:58:19 -0700 Received: by kerouac.projectcolo.org.uk (Postfix, from userid 10003) id 831937A015; Tue, 15 Jun 2004 10:58:17 +0100 (BST) Date: Tue, 15 Jun 2004 10:58:17 +0100 From: Mark Brown To: netdev@oss.sgi.com Subject: Re: Ethernet MAC address question Message-ID: <20040615095817.GA16523@projectcolo.org.uk> Mail-Followup-To: netdev@oss.sgi.com References: <200406142202.i5EM2bh19464@localhost.localdomain> <40CE361A.9060707@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CE361A.9060707@pobox.com> User-Agent: Mutt/1.3.28i X-Cookie: marriage, n.: X-archive-position: 5929 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: broonie@sirena.org.uk Precedence: bulk X-list: netdev Content-Length: 531 Lines: 12 On Mon, Jun 14, 2004 at 07:34:50PM -0400, Jeff Garzik wrote: > However there are a few cases where some magic platform means loads the > MAC address into the (volatile) MAC address registers, and that's the > only source of an accurate MAC address for those people. This is reasonably common on embedded systems - often there won't be SEPROMs for individual devices and the MAC address will be stored in flash or similar and read by the bootloader. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From hadi@cyberus.ca Tue Jun 15 05:27:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 05:27:36 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FCRUgi006023 for ; Tue, 15 Jun 2004 05:27:30 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BaD2E-0000rw-BF for netdev@oss.sgi.com; Tue, 15 Jun 2004 08:27:26 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BaD2B-0002Rg-SW; Tue, 15 Jun 2004 08:27:24 -0400 Subject: Re: in-driver QoS From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com In-Reply-To: <200406142353.28277.vkondra@mail.ru> References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406111619.40260.vkondra@mail.ru> <1086960639.1068.697.camel@jzny.localdomain> <200406142353.28277.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1087302412.1042.46.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jun 2004 08:26:52 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5930 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: 2745 Lines: 62 On Mon, 2004-06-14 at 16:53, Vladimir Kondratiev wrote: > Jamal, > let's list the features need to be provided for 802.11 QoS, and problems. > > It is worth to provide standard interface with wireless stack; otherwise each > driver will invent its own solution. > > 1. NIC have number of Tx DMA channels, with different channels used for > different priorities. It is dictated by standard (TGe). > > Most likely, it should be 4 queues for EDCA traffic (4 priorities), 1 for HCCA > (polled, pre-agreed streams) and optionally 1 for multicast traffic (AP need > it). > > Each queue need to start/stop separately. For flexibility, it should be some > way for driver to request queues and specify mapping to these queues. > > Ideas for how to implement it in stack? Refer to my earlier note on implementation. The only challenge is in starting and stopping each hardware DMA/FIFO separately. Thats whats missing today. The mapping between s/ware level queues and DMA/FIFO level is done via skb tags and is enforced via tc policies entered by the admin. Some of the current tags could be used or a new one created just for this. > Meanwhile, ideas how to get separate per-priority control with existing > infrastructure? like i said the qdisc infrastruture is in place. > 2. There is traffic that require admission control. Unless driver performs > allocation with AP, this traffic is not allowed. Is this admission control something like 802.1x/EAP? I think stuff like that belongs to user space. You could use the new tc extensions i have to redirect packets to a user space process which then installs tc policies based on some compute the user space app does (eg lookup some LDAP/RADIUS attributes etc) > TGe standard dictates it. > > Driver should participate in bandwidth allocation (via RSVP?). It should get > some form of request (IOCTL?) which it will serve by performing allocation on > link layer. It is easy to do proprietary IOCTL and white custom RSVP daemon, > but it is much better to do something generic for all drivers to use. There is nothing new here as far as linux is concerned. Driver doesnt participate in any of this directly. Traffic control is done by a layer above driver. By the time the packet gets to the driver, it just looks at the skb tag and maps it to the right DMA/FIFO (may stop the netif_queue for the FIFO etc) I dont know many people running RSVP or COPS for that matter. But we have the mechanisms for them in place. I know a lot of fscked people who will wanna do this via SNMP. And dont forget your bash scripts of course. Now imagine you trying to make all the above be aware of whatever your driver is supposed to be doing via ioctls. Not a very scalable idea. cheers, jamal From herbert@gondor.apana.org.au Tue Jun 15 05:44:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 05:44:39 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FCiQgi006705 for ; Tue, 15 Jun 2004 05:44: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 1BaDHv-0002tH-00; Tue, 15 Jun 2004 22:43:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BaDHq-0006YN-00; Tue, 15 Jun 2004 22:43:34 +1000 Date: Tue, 15 Jun 2004 22:43:34 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: IPsec and Path MTU Message-ID: <20040615124334.GA25164@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5931 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: 791 Lines: 21 Hi: Can someone explain the rationale behind dst->path and dst_pmtu to me? As far as I can see it was introduced specifically for IPsec. However, it seems to me that it makes no sense whatsoever in that case. As it is, the MTU for any peer with an IPsec policy is determined by the MTU of its dst->path. But this is wrong because it assigns a single MTU to all hosts behind an IPsec gateway, even though their paths may well diverge beyond the gateway. So unless I'm missing something, we should get rid of dst->path and store the MTU in the xfrm dst's directly. Comments? -- 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 Jun 15 05:54:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 05:55:04 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FCsvgi007233 for ; Tue, 15 Jun 2004 05:54:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BaDSo-0005do-7w for netdev@oss.sgi.com; Tue, 15 Jun 2004 08:54:54 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BaDSl-0007rr-JC; Tue, 15 Jun 2004 08:54:51 -0400 Subject: Re: ENOBUFS and dev_queue_xmit() From: jamal Reply-To: hadi@cyberus.ca To: Alex Pankratov Cc: netdev@oss.sgi.com In-Reply-To: <40CE818C.2090906@swapped.cc> References: <40CE818C.2090906@swapped.cc> Content-Type: text/plain Organization: jamalopolis Message-Id: <1087304060.1043.72.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jun 2004 08:54:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5932 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: 2255 Lines: 60 On Tue, 2004-06-15 at 00:56, Alex Pankratov wrote: > I've been poking around rather weird problem today where send() > on UDP socket was failing with ENETDOWN. When traced down to > the kernel, it happened to originate in dev_queue_xmit() - > > if (!netif_queue_stopped(dev)) { > ... > } > ... > $here > > meaning that the device's queue was stopped. The comment there > implies that only a broken virtual device may end up $here, How did you end up there with a real phy device?? Are you trying to circumvent the qdisc subsystem? If yes, you are responsible for how all this gets handled. > but > the fact is that I saw it for a physical interface running > slightly modified via-rhine driver. The original driver code > contains a snippet that stops the queue if its Tx ring buffer > becomes full - > > if (np->cur_tx == np->dirty_tx + TX_QUEUE_LEN) > netif_stop_queue(dev); > > and this code got actually executed with a hack applied. > At this point I thought that dev_queue_xmit() must be mistakenly > returning ENETDOWN instead of ENOBUFS, but looking at 'man 2 send' > I saw that - > > ENOBUFS > The output queue for a network interface was full...snip... > (Normally, this does not occur in Linux. Packets are > just silently dropped when a device queue overflows.) > > Hmmm... so I looked at e100 and tulip and these both stop the queue > too if they run out of buffers. In other words, the 'silently dropped' > clause from man page does not seem to be consistently followed. > > Is this a known (pseudo?) issue ? ENOBUFS makes much more sense > in this context. I can certainly check interface status (IFF_UP) > on every ENETDOWN to see what's the real cause, but that's kind > of ugly. Did you mean when no space is left in the ring? Thats different from ENOBUFF. If not, not sure i see how a driver xmit path gets involved in kmallocing. Look at the return code the driver returns. In case of a full ring, it should return a busy signal and the top layer will retry later. You dont have to worry about any of that if you are running the std linux semantics, of course. I have a feeling you have attempted to bypass it otherwise the question becomes: how you even ended in this situation. cheers, jamal From dag@bakke.com Tue Jun 15 07:19:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 07:20:02 -0700 (PDT) Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FEJngi009422 for ; Tue, 15 Jun 2004 07:19:49 -0700 Received: (cpmta 21267 invoked from network); 15 Jun 2004 07:19:48 -0700 Received: from 209.228.32.80 (HELO mail.bakke.com.criticalpath.net) by smtp.bakke.com (209.228.32.65) with SMTP; 15 Jun 2004 07:19:48 -0700 X-Sent: 15 Jun 2004 14:19:48 GMT Received: from [195.204.181.130] by mail.bakke.com with HTTP; Tue, 15 Jun 2004 07:19:48 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: netdev@oss.sgi.com From: dag@bakke.com Subject: 8139too.txt missing. X-Sent-From: dag@bakke.com Date: Tue, 15 Jun 2004 07:19:48 -0700 (PDT) X-Mailer: Web Mail 5.6.3-1 Message-Id: <20040615071948.7616.h016.c000.wm@mail.bakke.com.criticalpath.net> X-archive-position: 5933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dag@bakke.com Precedence: bulk X-list: netdev Content-Length: 307 Lines: 11 Hi. While trying to squeeze the last drop of performance out of a pair of RTL8139C cardbus cards in bonding mode, I found that 8139too.txt is missing from the 2.6 kernel source. Is this intentional? If so, should the module help text and the driver source be modified to not mention this file? Dag B. From dag@bakke.com Tue Jun 15 07:35:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 07:35:59 -0700 (PDT) Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FEZugi010054 for ; Tue, 15 Jun 2004 07:35:56 -0700 Received: (cpmta 27491 invoked from network); 15 Jun 2004 07:35:55 -0700 Received: from 209.228.32.80 (HELO mail.bakke.com.criticalpath.net) by smtp.bakke.com (209.228.32.64) with SMTP; 15 Jun 2004 07:35:55 -0700 X-Sent: 15 Jun 2004 14:35:55 GMT Received: from [195.204.181.130] by mail.bakke.com with HTTP; Tue, 15 Jun 2004 07:35:54 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: netdev@oss.sgi.com From: dag@bakke.com Subject: Troughput of dual 8139C/cardbus/bonding? X-Sent-From: dag@bakke.com Date: Tue, 15 Jun 2004 07:35:54 -0700 (PDT) X-Mailer: Web Mail 5.6.3-1 Message-Id: <20040615073555.8005.h016.c000.wm@mail.bakke.com.criticalpath.net> X-archive-position: 5934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dag@bakke.com Precedence: bulk X-list: netdev Content-Length: 1291 Lines: 34 Hi. (Jeff G., question for you further down.) Would anyone on this list be so kind as to share with me their thoughts on what troughput I should be able to obtain with two RTL8139C CardBus cards in bonding mode, talking to an identical twin in the other end of two crossed Ethernet cables? The PCs I have are Toshiba laptops with a ToPIC95 PCItoCardBus bridge and a 600MHz PIII. CardBus cards share the same interrupt. A single card gives me 95+ Mbps troughput (one or two-way udp traffic), two cards bonded offers at best 153 Mbps. (One way udp traffic) It doesn't look like the bonding driver is the cuplprit here. Doing testing with separate networks on each pair of Ethernet links does not give better aggregate performance. Furthermore, I find that the single-link performance occasionally drops to 80 Mbps, or even 67 Mbps. And stays there. The only way to get it back is by 'ifconfig down up' the interface. Is this a bug, or some throttling mechanism in the kernel kicking in? (Jeff....?) I am currently running 2.6.7-rc2 and testing with iperf 1.7.0. I'll happily provide more details to interested parties. I'll use this setup to field-test a pair of devices with multiple Ethernet ports in one end and a wireless (!) 155Mbps STM-1 interface in the other end. Dag B From mcr@sandelman.ottawa.on.ca Tue Jun 15 07:52:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 07:52:13 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FEq4gi010670 for ; Tue, 15 Jun 2004 07:52:09 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i5FEoiP12027 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 15 Jun 2004 10:50:45 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FEof36032710 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Jun 2004 10:50:41 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FEobIH032704; Tue, 15 Jun 2004 10:50:39 -0400 To: Herbert Xu cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU In-Reply-To: Message from Herbert Xu of "Tue, 15 Jun 2004 22:43:34 +1000." <20040615124334.GA25164@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 15 Jun 2004 10:50:37 -0400 Message-ID: <32703.1087311037@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 5935 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: 1815 Lines: 42 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Herbert" == Herbert Xu writes: Herbert> Can someone explain the rationale behind dst->path and Herbert> dst_pmtu to me? Herbert> As far as I can see it was introduced specifically for Herbert> IPsec. However, it seems to me that it makes no sense Herbert> whatsoever in that case. Herbert> As it is, the MTU for any peer with an IPsec policy is Herbert> determined by the MTU of its dst->path. But this is wrong Herbert> because it assigns a single MTU to all hosts behind an Herbert> IPsec gateway, even though their paths may well diverge Herbert> beyond the gateway. Herbert> So unless I'm missing something, we should get rid of Herbert> dst->path and store the MTU in the xfrm dst's directly. Not being too familiar with the code, but being very familiar with pmtu, what you say sounds perfect to me. The pmtu WG is considering changing how PMTU is done. You may want to look at draft-richardson-ipsec-fragment-XX.txt. This has not yet been adopted as a WG draft, because nobody is sure which WG should adopt it:-) - -- ] "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 iQCVAwUBQM8Mt4qHRg3pndX9AQFocwP+JLy04UB9HaNUGBLvmhW4Nf1+TDtdXZyY nWJVb1Jl96G3NUDn8nEwe0jfrFpUI8GmY9zPK+l7qonZzHaAym3fP7GWEKz1VKJu Ckzt76C+qjGVfwgPuYbKyGWDIaUiCIE1AEnJKbYTQMei12im6iGswPYvsOJNy/k/ LU2ABZZnWls= =bher -----END PGP SIGNATURE----- From yoshfuji@linux-ipv6.org Tue Jun 15 07:59:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 07:59:26 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FExMgi011205 for ; Tue, 15 Jun 2004 07:59:22 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 71D5833CE5; Wed, 16 Jun 2004 00:00:17 +0900 (JST) Date: Wed, 16 Jun 2004 00:00:10 +0900 (JST) Message-Id: <20040616.000010.111901629.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [IPV6] UDPv6: checksum 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: 5936 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: 641 Lines: 23 Hello. We always need to check UDPv6 checksum because it is mandatory. Thanks. ===== net/ipv6/udp.c 1.64 vs edited ===== --- 1.64/net/ipv6/udp.c 2004-06-10 05:39:26 +09:00 +++ edited/net/ipv6/udp.c 2004-06-15 23:43:42 +09:00 @@ -507,7 +507,7 @@ return -1; } - if (sk->sk_filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { + if (skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { UDP6_INC_STATS_BH(UdpInErrors); kfree_skb(skb); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Tue Jun 15 08:03:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 08:04:00 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FF3wgi011650 for ; Tue, 15 Jun 2004 08:03:59 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 7896C33CE6; Wed, 16 Jun 2004 00:04:54 +0900 (JST) Date: Wed, 16 Jun 2004 00:04:49 +0900 (JST) Message-Id: <20040616.000449.48351036.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [IPV6 2.4] UDPv6: checksum 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: 5937 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: 956 Lines: 32 Hello. We always need to check UDPv6 checksum because it is mandatory. This patch is for 2.4. Thanks. ===== net/ipv6/udp.c 1.14 vs edited ===== --- 1.14/net/ipv6/udp.c 2004-02-25 17:19:02 +09:00 +++ edited/net/ipv6/udp.c 2004-06-15 23:45:18 +09:00 @@ -521,8 +521,7 @@ static inline int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb) { -#if defined(CONFIG_FILTER) - if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { + if (skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { UDP6_INC_STATS_BH(UdpInErrors); IP6_INC_STATS_BH(Ip6InDiscards); @@ -531,7 +530,6 @@ } skb->ip_summed = CHECKSUM_UNNECESSARY; } -#endif if (sock_queue_rcv_skb(sk,skb)<0) { UDP6_INC_STATS_BH(UdpInErrors); IP6_INC_STATS_BH(Ip6InDiscards); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Tue Jun 15 08:09:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 08:09:30 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FF9Pgi012159 for ; Tue, 15 Jun 2004 08:09:26 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4D3AC33CE7; Wed, 16 Jun 2004 00:10:21 +0900 (JST) Date: Wed, 16 Jun 2004 00:10:16 +0900 (JST) Message-Id: <20040616.001016.54016316.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [2.4,IPV6] UDPv6: use udpv6_queue_rcv_skb(). 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: 5938 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: 1332 Lines: 56 Hello. Use udpv6_queue_rcv_skb() instead of sock_queue_rcv_skb() as we do in 2.6 for checksum, (ipsec and) statistics. ===== net/ipv6/udp.c 1.14 vs edited ===== --- 1.14/net/ipv6/udp.c 2004-02-25 17:19:02 +09:00 +++ edited/net/ipv6/udp.c 2004-06-15 23:50:47 +09:00 @@ -586,34 +586,26 @@ struct sk_buff *skb) { struct sock *sk, *sk2; - struct sk_buff *buff; int dif; read_lock(&udp_hash_lock); sk = udp_hash[ntohs(uh->dest) & (UDP_HTABLE_SIZE - 1)]; dif = skb->dev->ifindex; sk = udp_v6_mcast_next(sk, uh->dest, daddr, uh->source, saddr, dif); - if (!sk) - goto free_skb; + if (!sk) { + kfree_skb(skb); + goto out; + } - buff = NULL; sk2 = sk; while((sk2 = udp_v6_mcast_next(sk2->next, uh->dest, daddr, uh->source, saddr, dif))) { - if (!buff) { - buff = skb_clone(skb, GFP_ATOMIC); - if (!buff) - continue; - } - if (sock_queue_rcv_skb(sk2, buff) >= 0) - buff = NULL; - } - if (buff) - kfree_skb(buff); - if (sock_queue_rcv_skb(sk, skb) < 0) { -free_skb: - kfree_skb(skb); + struct sk_buff *buff = skb_clone(skb, GFP_ATOMIC); + if (buff) + udpv6_queue_rcv_skb(sk2, buff); } + udpv6_queue_rcv_skb(sk, skb); +out: read_unlock(&udp_hash_lock); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ap@swapped.cc Tue Jun 15 08:39:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 08:39:47 -0700 (PDT) Received: from mx.coredump.cc (S010600105aa5438e.vc.shawcable.net [24.87.213.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FFdigi016294 for ; Tue, 15 Jun 2004 08:39:44 -0700 Received: (qmail 29350 invoked from network); 15 Jun 2004 15:50:26 -0000 Received: from unknown (HELO swapped.cc) (10.0.0.104) by 10.0.0.1 with SMTP; 15 Jun 2004 15:50:26 -0000 Message-ID: <40CF182F.4060401@swapped.cc> Date: Tue, 15 Jun 2004 08:39:27 -0700 From: Alex Pankratov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: netdev@oss.sgi.com Subject: Re: ENOBUFS and dev_queue_xmit() References: <40CE818C.2090906@swapped.cc> <1087304060.1043.72.camel@jzny.localdomain> In-Reply-To: <1087304060.1043.72.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ap@swapped.cc Precedence: bulk X-list: netdev Content-Length: 1596 Lines: 42 jamal wrote: > On Tue, 2004-06-15 at 00:56, Alex Pankratov wrote: > >>I've been poking around rather weird problem today where send() [snip] >>meaning that the device's queue was stopped. The comment there >>implies that only a broken virtual device may end up $here, > > > How did you end up there with a real phy device?? Are you trying to > circumvent the qdisc subsystem? If yes, you are responsible for how > all this gets handled. Now that I looked at dev.c code again I ask myself the very same questions :) I am not circumventing qdisc, at least intentionally, and I don't do anything fancy with dev->qdisc. It must be a bug due to some of my changes, ignore the original question. Thanks for your help. >> >>Is this a known (pseudo?) issue ? ENOBUFS makes much more sense >>in this context. I can certainly check interface status (IFF_UP) >>on every ENETDOWN to see what's the real cause, but that's kind >>of ugly. > > Did you mean when no space is left in the ring? Thats different > from ENOBUFF. If not, not sure i see how a driver xmit path gets > involved in kmallocing. > Look at the return code the driver returns. In case of a full ring, it > should return a busy signal and the top layer will retry later. > You dont have to worry about any of that if you are running the > std linux semantics, of course. I have a feeling you have attempted to > bypass it otherwise the question becomes: how you even ended in this > situation. > I'm pretty sure you're right about breaking the semantics. I'll check it out, and re-complain if it's not my problem. Thanks again. From brazilnut@us.ibm.com Tue Jun 15 08:41:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 08:41:38 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FFfZgi016503 for ; Tue, 15 Jun 2004 08:41:35 -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.2) with ESMTP id i5FFfSY0504582; Tue, 15 Jun 2004 11:41:28 -0400 Received: from localhost.localdomain (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FFfRPg316398; Tue, 15 Jun 2004 09:41:28 -0600 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5FFcJ720553; Tue, 15 Jun 2004 08:38:19 -0700 From: Don Fry Message-Id: <200406151538.i5FFcJ720553@localhost.localdomain> Subject: Re: Ethernet MAC address question To: broonie@sirena.org.uk (Mark Brown) Date: Tue, 15 Jun 2004 08:38:19 -0700 (PDT) Cc: netdev@oss.sgi.com In-Reply-To: <20040615095817.GA16523@projectcolo.org.uk> from "Mark Brown" at Jun 15, 2004 10:58:17 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5940 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: 781 Lines: 18 So how does the driver distinguish between a valid, but incorrect MAC address, and the 'correct' MAC address? The incorrect one that is the value that just happened to be in the uninitialized volatile registers, and the correct address which some magic platform means loaded into the same, but this time initialized, volatile registers. > > However there are a few cases where some magic platform means loads the > > MAC address into the (volatile) MAC address registers, and that's the > > only source of an accurate MAC address for those people. > > This is reasonably common on embedded systems - often there won't be > SEPROMs for individual devices and the MAC address will be stored in > flash or similar and read by the bootloader. > -- Don Fry brazilnut@us.ibm.com From DanE@aiinet.com Tue Jun 15 08:50:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 08:50:10 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FFo7gi017197 for ; Tue, 15 Jun 2004 08:50:08 -0700 Received: by AIMAIL1.ai.aiinet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jun 2004 11:50:01 -0400 Message-ID: From: "Eble, Dan" To: "'netdev@oss.sgi.com'" Subject: serial port-to-netdevice tap Date: Tue, 15 Jun 2004 11:50:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 5941 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 Content-Length: 482 Lines: 11 A coworker of mine wants an easy way to monitor data transfer and control line changes on an serial port. His first impulse was to create a /proc file, but I suggested a netlink socket, or even a raw net device so that he can take advantage of libpcap for some pretty powerful filtering. Does anything like this exist already? -- Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| From vkondra@mail.ru Tue Jun 15 09:37:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 09:37:13 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FGb6gi018800 for ; Tue, 15 Jun 2004 09:37:07 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 79D9BE8E12 for ; Tue, 15 Jun 2004 20:36:47 +0400 (MSD) Received: from [62.219.156.227] (port=28365 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BaGuT-0003Rn-00; Tue, 15 Jun 2004 20:35:43 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: in-driver QoS Date: Tue, 15 Jun 2004 19:35:04 +0300 User-Agent: KMail/1.6.2 References: <20040608184831.GA18462@bougret.hpl.hp.com> <200406142353.28277.vkondra@mail.ru> <1087302412.1042.46.camel@jzny.localdomain> In-Reply-To: <1087302412.1042.46.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406151935.08568.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5FGb6gi018800 X-archive-position: 5942 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: 3881 Lines: 87 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 15 June 2004 15:26, jamal wrote: > On Mon, 2004-06-14 at 16:53, Vladimir Kondratiev wrote: > > Jamal, > > let's list the features need to be provided for 802.11 QoS, and problems. > > > > It is worth to provide standard interface with wireless stack; otherwise > > each driver will invent its own solution. > > > > 1. NIC have number of Tx DMA channels, with different channels used for > > different priorities. It is dictated by standard (TGe). > > > > Most likely, it should be 4 queues for EDCA traffic (4 priorities), 1 for > > HCCA (polled, pre-agreed streams) and optionally 1 for multicast traffic > > (AP need it). > > > > Each queue need to start/stop separately. For flexibility, it should be > > some way for driver to request queues and specify mapping to these > > queues. > > > > Ideas for how to implement it in stack? > > Refer to my earlier note on implementation. > The only challenge is in starting and stopping each hardware DMA/FIFO > separately. Thats whats missing today. > The mapping between s/ware level queues and DMA/FIFO level is done via > skb tags and is enforced via tc policies entered by the admin. Some of > the current tags could be used or a new one created just for this. Sure, skb->priority is what I use currently to map packets to queue. > > > Meanwhile, ideas how to get separate per-priority control with existing > > infrastructure? > > like i said the qdisc infrastruture is in place. Examples? Do you know some driver that uses it? > > > 2. There is traffic that require admission control. Unless driver > > performs allocation with AP, this traffic is not allowed. > > Is this admission control something like 802.1x/EAP? > I think stuff like that belongs to user space. You could use the new tc > extensions i have to redirect packets to a user space process which then > installs tc policies based on some compute the user space app does (eg > lookup some LDAP/RADIUS attributes etc) It is different kind of admission. 802.1x is about opening port, and is done above MAC using data packets. It is exactly like TSPEC below. For TSPEC, it is MAC level protocol, implemented with management packets. Idea here is that high priority EDCA(contention access) channels should be controlled. Otherwise one can Tx all traffic at high priority. > > > TGe standard dictates it. > > > > Driver should participate in bandwidth allocation (via RSVP?). It should > > get some form of request (IOCTL?) which it will serve by performing > > allocation on link layer. It is easy to do proprietary IOCTL and white > > custom RSVP daemon, but it is much better to do something generic for all > > drivers to use. > > There is nothing new here as far as linux is concerned. Driver doesnt > participate in any of this directly. Traffic control is done by a layer > above driver. By the time the packet gets to the driver, it just looks > at the skb tag and maps it to the right DMA/FIFO (may stop the > netif_queue for the FIFO etc) My point is, in order to made this stream valid, driver should perform some handshake with AP. Driver should send management packet and get response. If handshake is not done, this packet will be rejected by AP, and station will be thrown out of network for protocol violation. > I dont know many people running RSVP or COPS for that matter. But we > have the mechanisms for them in place. I know a lot of fscked people who > will wanna do this via SNMP. And dont forget your bash scripts of > course. > Now imagine you trying to make all the above be aware of whatever your > driver is supposed to be doing via ioctls. Not a very scalable idea. > > cheers, > jamal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAzyU8qxdj7mhC6o0RAizzAKCsd2wZcSqMa3pJ7FKduTdUU2lPawCfdcg8 RaW20rmN9hwifwwIFjgKHRE= =MpoC -----END PGP SIGNATURE----- From gwingerde@home.nl Tue Jun 15 09:48:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 09:49:03 -0700 (PDT) Received: from smtpq1.home.nl (smtpq1.home.nl [213.51.128.196]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FGmigi019377 for ; Tue, 15 Jun 2004 09:48:47 -0700 Received: from [213.51.128.134] (port=49241 helo=smtp3.home.nl) by smtpq1.home.nl with esmtp (Exim 4.30) id 1BaH75-0006jo-RP; Tue, 15 Jun 2004 18:48:43 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([212.120.112.51]:33763 helo=[192.168.14.1]) by smtp3.home.nl with esmtp (Exim 4.30) id 1BaH75-0004yM-1d; Tue, 15 Jun 2004 18:48:43 +0200 Message-ID: <40CF263E.70009@home.nl> Date: Tue, 15 Jun 2004 18:39:26 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 0.6 (X11/20040526) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink References: In-Reply-To: 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: 5943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Content-Length: 1304 Lines: 49 Scott, Sounds like a good idea. I'll start refactoring my work towards that approach. Please bear with me for a couple of days and I'll post a draft patch for this. --- Gertjan. Feldman, Scott wrote: >>I was thinking along the same lines, however I was taking the >>ethtool interface as the starting point (using a single ioctl >>for all wireless operations). The private handlers would just >>have to be converted to plain ioctls handled by the driver itself. >> >>The attached patch can be used as a starting point for this. >>It is not complete (not by far), but it shows the basic structure. >>I've called the structure wlantool_ops, again using the >>example set by ethtool. >> >>Comments? > > > What if we just use the ethtool ioctl that's already defined, and extend > ethtool with a wireless option: > > ethtool -w DEVNAME \ > [ nwid N|off|on} ] \ > [ freq x.xx ] \ > [ mode ad-hoc|managed|master|repeater|... ] \ > [ sens N ] \ > [ ... ] > > Each one of the sub-options to -w would have it's own ETHTOOL_[G|S]W... > command as well as a type-safe ethtool_op. > > Running ethtool DEVNAME dumps ETHTOOL_GW... : > > Wireless settings for eth0: > nwid: AB34 > freq: 2.422G > mode: managed > sens: -80 > > Good/bad idea? > > -scott > > From vkondra@mail.ru Tue Jun 15 10:23:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 10:23:03 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FHMxgi024506 for ; Tue, 15 Jun 2004 10:23:00 -0700 Received: from [62.219.156.227] (port=38807 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BaHeC-000Dm7-00; Tue, 15 Jun 2004 21:22:58 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink Date: Tue, 15 Jun 2004 20:22:29 +0300 User-Agent: KMail/1.6.2 Cc: Gertjan van Wingerde , "Feldman, Scott" References: <40CF263E.70009@home.nl> In-Reply-To: <40CF263E.70009@home.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406152022.34904.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5FHMxgi024506 X-archive-position: 5944 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: 1805 Lines: 61 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like this idea too. When patches will be ready, I am willing to convert my driver to use this interface, and I'll provide feedback. Vladimir. On Tuesday 15 June 2004 19:39, Gertjan van Wingerde wrote: > Scott, > > Sounds like a good idea. I'll start refactoring my work towards that > approach. Please bear with me for a couple of days and I'll post a draft > patch for this. > > --- Gertjan. > > Feldman, Scott wrote: > >>I was thinking along the same lines, however I was taking the > >>ethtool interface as the starting point (using a single ioctl > >>for all wireless operations). The private handlers would just > >>have to be converted to plain ioctls handled by the driver itself. > >> > >>The attached patch can be used as a starting point for this. > >>It is not complete (not by far), but it shows the basic structure. > >>I've called the structure wlantool_ops, again using the > >>example set by ethtool. > >> > >>Comments? > > > > What if we just use the ethtool ioctl that's already defined, and extend > > ethtool with a wireless option: > > > > ethtool -w DEVNAME \ > > [ nwid N|off|on} ] \ > > [ freq x.xx ] \ > > [ mode ad-hoc|managed|master|repeater|... ] \ > > [ sens N ] \ > > [ ... ] > > > > Each one of the sub-options to -w would have it's own ETHTOOL_[G|S]W... > > command as well as a type-safe ethtool_op. > > > > Running ethtool DEVNAME dumps ETHTOOL_GW... : > > > > Wireless settings for eth0: > > nwid: AB34 > > freq: 2.422G > > mode: managed > > sens: -80 > > > > Good/bad idea? > > > > -scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAzzBaqxdj7mhC6o0RAjveAJ94RhRFBBYxewaSYuELds8HJXkntACcCQDW 7SxvO7j/88hGxeAL3g8zQ8k= =iYxo -----END PGP SIGNATURE----- From jgarzik@pobox.com Tue Jun 15 10:25:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 10:25:44 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FHPagi024854 for ; Tue, 15 Jun 2004 10:25:36 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BaGX6-0008O1-Mc; Tue, 15 Jun 2004 17:11:32 +0100 Message-ID: <40CF1FA6.3020701@pobox.com> Date: Tue, 15 Jun 2004 12:11:18 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: Mark Brown , netdev@oss.sgi.com Subject: Re: Ethernet MAC address question References: <200406151538.i5FFcJ720553@localhost.localdomain> In-Reply-To: <200406151538.i5FFcJ720553@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5945 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: 858 Lines: 21 Don Fry wrote: > So how does the driver distinguish between a valid, but incorrect MAC > address, and the 'correct' MAC address? The incorrect one that is the > value that just happened to be in the uninitialized volatile registers, > and the correct address which some magic platform means loaded into the > same, but this time initialized, volatile registers. You have to notice that certain platform-specific attributes are present, that tells your code to search in rather than the standard place for MAC address. For example, some Compaqs have a magic MAC address location (this might even be pcnet32), and one solution proposed was looking for the platform's DMI table identifiers. Another solution -- working -- was to load the MAC address registers when the driver loads, and just hope it is a correct address. Jeff From rl@hellgate.ch Tue Jun 15 10:49:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 10:49:05 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FHmxgi025858 for ; Tue, 15 Jun 2004 10:49:00 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD3003EDBF5; Tue, 15 Jun 2004 17:48:25 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id CB51F21F343; Tue, 15 Jun 2004 19:48:22 +0200 (CEST) Date: Tue, 15 Jun 2004 19:48:22 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [1/9][PATCH 2.6] Restructure reset code Message-ID: <20040615174822.GA11107@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 6816 Lines: 265 Restructure code to make it easier to maintain. rhine_hw_init: resets chip, reloads eeprom rhine_chip_reset: chip reset + what used to be wait_for_reset rhine_reload_eeprom: reload eeprom, re-enable MMIO, disable EEPROM-controlled WOL Note: Chip reset clears a bunch of registers that should be reloaded from EEPROM (which turns off MMIO). Deal with that later. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -579,56 +579,76 @@ } } -static void wait_for_reset(struct net_device *dev, u32 quirks, char *name) +static void rhine_chip_reset(struct net_device *dev) { long ioaddr = dev->base_addr; + struct rhine_private *rp = netdev_priv(dev); int boguscnt = 20; + writew(CmdReset, ioaddr + ChipCmd); IOSYNC; if (readw(ioaddr + ChipCmd) & CmdReset) { printk(KERN_INFO "%s: Reset not complete yet. " - "Trying harder.\n", name); + "Trying harder.\n", DRV_NAME); - /* Rhine-II needs to be forced sometimes */ - if (quirks & rqForceReset) + /* Force reset */ + if (rp->quirks & rqForceReset) writeb(0x40, ioaddr + MiscCmd); - /* VT86C100A may need long delay after reset (dlink) */ - /* Seen on Rhine-II as well (rl) */ + /* Reset can take somewhat longer (rare) */ while ((readw(ioaddr + ChipCmd) & CmdReset) && --boguscnt) udelay(5); - } if (debug > 1) - printk(KERN_INFO "%s: Reset %s.\n", name, + printk(KERN_INFO "%s: Reset %s.\n", pci_name(rp->pdev), boguscnt ? "succeeded" : "failed"); } #ifdef USE_MMIO -static void __devinit enable_mmio(long ioaddr, u32 quirks) +static void __devinit enable_mmio(long pioaddr, u32 quirks) { int n; if (quirks & rqRhineI) { /* More recent docs say that this bit is reserved ... */ - n = inb(ioaddr + ConfigA) | 0x20; - outb(n, ioaddr + ConfigA); + n = inb(pioaddr + ConfigA) | 0x20; + outb(n, pioaddr + ConfigA); } else { - n = inb(ioaddr + ConfigD) | 0x80; - outb(n, ioaddr + ConfigD); + n = inb(pioaddr + ConfigD) | 0x80; + outb(n, pioaddr + ConfigD); } } #endif -static void __devinit reload_eeprom(long ioaddr) +/* + * Loads bytes 0x00-0x05, 0x6E-0x6F, 0x78-0x7B from EEPROM + */ +static void __devinit rhine_reload_eeprom(long pioaddr, struct net_device *dev) { + long ioaddr = dev->base_addr; + struct rhine_private *rp = netdev_priv(dev); int i; - outb(0x20, ioaddr + MACRegEEcsr); + + outb(0x20, pioaddr + MACRegEEcsr); /* Typically 2 cycles to reload. */ for (i = 0; i < 150; i++) - if (! (inb(ioaddr + MACRegEEcsr) & 0x20)) + if (! (inb(pioaddr + MACRegEEcsr) & 0x20)) break; + +#ifdef USE_MMIO + /* + * Reloading from EEPROM overwrites ConfigA-D, so we must re-enable + * MMIO. If reloading EEPROM was done first this could be avoided, but + * it is not known if that still works with the "win98-reboot" problem. + */ + enable_mmio(pioaddr, rp->quirks); +#endif + + /* Turn off EEPROM-controlled wake-up (magic packet) */ + if (rp->quirks & rqWOL) + writeb(readb(ioaddr + ConfigA) & 0xFE, ioaddr + ConfigA); + } #ifdef CONFIG_NET_POLL_CONTROLLER @@ -640,6 +660,15 @@ } #endif +static void rhine_hw_init(struct net_device *dev, long pioaddr) +{ + /* Reset the chip to erase previous misconfiguration. */ + rhine_chip_reset(dev); + + /* Reload EEPROM controlled bytes cleared by soft reset */ + rhine_reload_eeprom(pioaddr, dev); +} + static int __devinit rhine_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -649,13 +678,11 @@ u8 pci_rev; u32 quirks; static int card_idx = -1; - long ioaddr; + long pioaddr; long memaddr; + long ioaddr; int io_size; int phy, phy_idx = 0; -#ifdef USE_MMIO - long ioaddr0; -#endif const char *name; /* when built into the kernel, we only print version if device is found */ @@ -708,7 +735,7 @@ goto err_out; } - ioaddr = pci_resource_start(pdev, 0); + pioaddr = pci_resource_start(pdev, 0); memaddr = pci_resource_start(pdev, 1); pci_set_master(pdev); @@ -728,8 +755,7 @@ goto err_out_free_netdev; #ifdef USE_MMIO - ioaddr0 = ioaddr; - enable_mmio(ioaddr0, quirks); + enable_mmio(pioaddr, quirks); ioaddr = (long) ioremap(memaddr, io_size); if (!ioaddr) { @@ -743,7 +769,7 @@ i = 0; while (mmio_verify_registers[i]) { int reg = mmio_verify_registers[i++]; - unsigned char a = inb(ioaddr0+reg); + unsigned char a = inb(pioaddr+reg); unsigned char b = readb(ioaddr+reg); if (a != b) { rc = -EIO; @@ -752,26 +778,18 @@ goto err_out_unmap; } } +#else + ioaddr = pioaddr; #endif /* USE_MMIO */ + dev->base_addr = ioaddr; + rp = netdev_priv(dev); + rp->quirks = quirks; rhine_power_init(dev); /* Reset the chip to erase previous misconfiguration. */ - writew(CmdReset, ioaddr + ChipCmd); - - wait_for_reset(dev, quirks, shortname); - - /* Reload the station address from the EEPROM. */ -#ifdef USE_MMIO - reload_eeprom(ioaddr0); - /* Reloading from eeprom overwrites cfgA-D, so we must re-enable MMIO. - If reload_eeprom() was done first this could be avoided, but it is - not known if that still works with the "win98-reboot" problem. */ - enable_mmio(ioaddr0, quirks); -#else - reload_eeprom(ioaddr); -#endif + rhine_hw_init(dev, pioaddr); for (i = 0; i < 6; i++) dev->dev_addr[i] = readb(ioaddr + StationAddr + i); @@ -782,15 +800,6 @@ goto err_out_unmap; } - if (quirks & rqWOL) { - /* - * for 3065D, EEPROM reloaded will cause bit 0 in MAC_REG_CFGA - * turned on. it makes MAC receive magic packet - * automatically. So, we turn it off. (D-Link) - */ - writeb(readb(ioaddr + ConfigA) & 0xFE, ioaddr + ConfigA); - } - /* Select backoff algorithm */ if (backoff) writeb(readb(ioaddr + ConfigD) & (0xF0 | backoff), @@ -798,10 +807,8 @@ dev->irq = pdev->irq; - rp = netdev_priv(dev); spin_lock_init(&rp->lock); rp->pdev = pdev; - rp->quirks = quirks; rp->mii_if.dev = dev; rp->mii_if.mdio_read = mdio_read; rp->mii_if.mdio_write = mdio_write; @@ -1170,9 +1177,6 @@ long ioaddr = dev->base_addr; int i; - /* Reset the chip. */ - writew(CmdReset, ioaddr + ChipCmd); - i = request_irq(rp->pdev->irq, &rhine_interrupt, SA_SHIRQ, dev->name, dev); if (i) @@ -1187,7 +1191,7 @@ return i; alloc_rbufs(dev); alloc_tbufs(dev); - wait_for_reset(dev, rp->quirks, dev->name); + rhine_chip_reset(dev); init_registers(dev); if (debug > 2) printk(KERN_DEBUG "%s: Done rhine_open(), status %4.4x " @@ -1283,9 +1287,6 @@ spin_lock(&rp->lock); - /* Reset the chip. */ - writew(CmdReset, ioaddr + ChipCmd); - /* clear all descriptors */ free_tbufs(dev); free_rbufs(dev); @@ -1293,7 +1294,7 @@ alloc_rbufs(dev); /* Reinitialize the hardware. */ - wait_for_reset(dev, rp->quirks, dev->name); + rhine_chip_reset(dev); init_registers(dev); spin_unlock(&rp->lock); From rl@hellgate.ch Tue Jun 15 10:49:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 10:49:55 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FHnogi026069 for ; Tue, 15 Jun 2004 10:49:51 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C001FCA51; Tue, 15 Jun 2004 17:49:43 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 13B4D21F343; Tue, 15 Jun 2004 19:49:42 +0200 (CEST) Date: Tue, 15 Jun 2004 19:49:42 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [7/9][PATCH 2.6] Media mode rewrite Message-ID: <20040615174942.GA11319@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 9310 Lines: 317 Remove rhine_check_duplex, rhine_timer and related data structures Add rhine_check_media: wrapper for generic mii_check_media, sets duplex bit in MAC Add rhine_enable_linkmon, rhine_disable_linkmon to enable hardware link status monitoring Update mdio_read, mdio_write accordingly Remove get_intr_status check in rhine_start_tx because we are not racing anymore Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -485,7 +485,6 @@ struct pci_dev *pdev; struct net_device_stats stats; - struct timer_list timer; /* Media monitoring timer. */ spinlock_t lock; /* Frequently used values: keep some adjacent for cache effect. */ @@ -498,16 +497,12 @@ /* These values are keep track of the transceiver/media in use. */ u8 tx_thresh, rx_thresh; - /* MII transceiver section. */ - u16 mii_status; /* last read MII status */ struct mii_if_info mii_if; }; static int mdio_read(struct net_device *dev, int phy_id, int location); static void mdio_write(struct net_device *dev, int phy_id, int location, int value); static int rhine_open(struct net_device *dev); -static void rhine_check_duplex(struct net_device *dev); -static void rhine_timer(unsigned long data); static void rhine_tx_timeout(struct net_device *dev); static int rhine_start_tx(struct sk_buff *skb, struct net_device *dev); static irqreturn_t rhine_interrupt(int irq, void *dev_instance, struct pt_regs *regs); @@ -1032,6 +1027,21 @@ } } +static void rhine_check_media(struct net_device *dev, unsigned int init_media) +{ + struct rhine_private *rp = netdev_priv(dev); + long ioaddr = dev->base_addr; + + mii_check_media(&rp->mii_if, debug, init_media); + + if (rp->mii_if.full_duplex) + writeb(readb(ioaddr + ChipCmd1) | Cmd1FDuplex, + ioaddr + ChipCmd1); + else + writeb(readb(ioaddr + ChipCmd1) & ~Cmd1FDuplex, + ioaddr + ChipCmd1); +} + static void init_registers(struct net_device *dev) { struct rhine_private *rp = netdev_priv(dev); @@ -1047,7 +1057,6 @@ writeb(0x20, ioaddr + TxConfig); rp->tx_thresh = 0x20; rp->rx_thresh = 0x60; /* Written in rhine_set_rx_mode(). */ - rp->mii_if.full_duplex = 0; writel(rp->rx_ring_dma, ioaddr + RxRingPtr); writel(rp->tx_ring_dma, ioaddr + TxRingPtr); @@ -1063,14 +1072,42 @@ writew(CmdStart|CmdTxOn|CmdRxOn|(Cmd1NoTxPoll << 8), ioaddr + ChipCmd); - if (rp->mii_if.force_media) - writeb(readb(ioaddr + ChipCmd1) | Cmd1FDuplex, - ioaddr + ChipCmd1); - else - writeb(readb(ioaddr + ChipCmd1) & ~Cmd1FDuplex, - ioaddr + ChipCmd1); + rhine_check_media(dev, 1); +} + +/* Enable MII link status auto-polling (required for IntrLinkChange) */ +static void rhine_enable_linkmon(long ioaddr) +{ + writeb(0, ioaddr + MIICmd); + writeb(MII_BMSR, ioaddr + MIIRegAddr); + writeb(0x80, ioaddr + MIICmd); - rhine_check_duplex(dev); + RHINE_WAIT_FOR((readb(ioaddr + MIIRegAddr) & 0x20)); + + writeb(MII_BMSR | 0x40, ioaddr + MIIRegAddr); +} + +/* Disable MII link status auto-polling (required for MDIO access) */ +static void rhine_disable_linkmon(long ioaddr, u32 quirks) +{ + writeb(0, ioaddr + MIICmd); + + if (quirks & rqRhineI) { + writeb(0x01, ioaddr + MIIRegAddr); // MII_BMSR + + /* Can be called from ISR. Evil. */ + mdelay(1); + + /* 0x80 must be set immediately before turning it off */ + writeb(0x80, ioaddr + MIICmd); + + RHINE_WAIT_FOR(readb(ioaddr + MIIRegAddr) & 0x20); + + /* Heh. Now clear 0x80 again. */ + writeb(0, ioaddr + MIICmd); + } + else + RHINE_WAIT_FOR(readb(ioaddr + MIIRegAddr) & 0x80); } /* Read and write over the MII Management Data I/O (MDIO) interface. */ @@ -1078,15 +1115,20 @@ static int mdio_read(struct net_device *dev, int phy_id, int regnum) { long ioaddr = dev->base_addr; + struct rhine_private *rp = netdev_priv(dev); + int result; - /* Wait for a previous command to complete. */ - RHINE_WAIT_FOR(!(readb(ioaddr + MIICmd) & 0x60)); - writeb(0x00, ioaddr + MIICmd); + rhine_disable_linkmon(ioaddr, rp->quirks); + + writeb(0, ioaddr + MIICmd); writeb(phy_id, ioaddr + MIIPhyAddr); writeb(regnum, ioaddr + MIIRegAddr); writeb(0x40, ioaddr + MIICmd); /* Trigger read */ RHINE_WAIT_FOR(!(readb(ioaddr + MIICmd) & 0x40)); - return readw(ioaddr + MIIData); + result = readw(ioaddr + MIIData); + + rhine_enable_linkmon(ioaddr); + return result; } static void mdio_write(struct net_device *dev, int phy_id, int regnum, int value) @@ -1094,29 +1136,17 @@ struct rhine_private *rp = netdev_priv(dev); long ioaddr = dev->base_addr; - if (phy_id == rp->mii_if.phy_id) { - switch (regnum) { - case MII_BMCR: /* Is user forcing speed/duplex? */ - if (value & 0x9000) /* Autonegotiation. */ - rp->mii_if.force_media = 0; - else - rp->mii_if.full_duplex = (value & 0x0100) ? 1 : 0; - break; - case MII_ADVERTISE: - rp->mii_if.advertising = value; - break; - } - } + rhine_disable_linkmon(ioaddr, rp->quirks); - /* Wait for a previous command to complete. */ - RHINE_WAIT_FOR(!(readb(ioaddr + MIICmd) & 0x60)); - writeb(0x00, ioaddr + MIICmd); + writeb(0, ioaddr + MIICmd); writeb(phy_id, ioaddr + MIIPhyAddr); writeb(regnum, ioaddr + MIIRegAddr); writew(value, ioaddr + MIIData); writeb(0x20, ioaddr + MIICmd); /* Trigger write. */ -} + RHINE_WAIT_FOR(!(readb(ioaddr + MIICmd) & 0x20)); + rhine_enable_linkmon(ioaddr); +} static int rhine_open(struct net_device *dev) { @@ -1148,78 +1178,9 @@ netif_start_queue(dev); - /* Set the timer to check for link beat. */ - init_timer(&rp->timer); - rp->timer.expires = jiffies + 2 * HZ/100; - rp->timer.data = (unsigned long)dev; - rp->timer.function = &rhine_timer; /* timer handler */ - add_timer(&rp->timer); - return 0; } -static void rhine_check_duplex(struct net_device *dev) -{ - struct rhine_private *rp = netdev_priv(dev); - long ioaddr = dev->base_addr; - int mii_lpa = mdio_read(dev, rp->mii_if.phy_id, MII_LPA); - int negotiated = mii_lpa & rp->mii_if.advertising; - int duplex; - - if (rp->mii_if.force_media || mii_lpa == 0xffff) - return; - duplex = (negotiated & 0x0100) || (negotiated & 0x01C0) == 0x0040; - if (rp->mii_if.full_duplex != duplex) { - rp->mii_if.full_duplex = duplex; - if (debug) - printk(KERN_INFO "%s: Setting %s-duplex based on " - "MII #%d link partner capability of %4.4x.\n", - dev->name, duplex ? "full" : "half", - rp->mii_if.phy_id, mii_lpa); - if (duplex) - writeb(readb(ioaddr + ChipCmd1) | Cmd1FDuplex, - ioaddr + ChipCmd1); - else - writeb(readb(ioaddr + ChipCmd1) & ~Cmd1FDuplex, - ioaddr + ChipCmd1); - } -} - - -static void rhine_timer(unsigned long data) -{ - struct net_device *dev = (struct net_device *)data; - struct rhine_private *rp = netdev_priv(dev); - long ioaddr = dev->base_addr; - int next_tick = 10*HZ; - int mii_status; - - if (debug > 3) { - printk(KERN_DEBUG "%s: VIA Rhine monitor tick, status %4.4x.\n", - dev->name, readw(ioaddr + IntrStatus)); - } - - spin_lock_irq (&rp->lock); - - rhine_check_duplex(dev); - - /* make IFF_RUNNING follow the MII status bit "Link established" */ - mii_status = mdio_read(dev, rp->mii_if.phy_id, MII_BMSR); - if ((mii_status & BMSR_LSTATUS) != (rp->mii_status & BMSR_LSTATUS)) { - if (mii_status & BMSR_LSTATUS) - netif_carrier_on(dev); - else - netif_carrier_off(dev); - } - rp->mii_status = mii_status; - - spin_unlock_irq(&rp->lock); - - rp->timer.expires = jiffies + next_tick; - add_timer(&rp->timer); -} - - static void rhine_tx_timeout(struct net_device *dev) { struct rhine_private *rp = netdev_priv(dev); @@ -1256,8 +1217,8 @@ static int rhine_start_tx(struct sk_buff *skb, struct net_device *dev) { struct rhine_private *rp = netdev_priv(dev); + long ioaddr = dev->base_addr; unsigned entry; - u32 intr_status; /* Caution: the write order is important here, set the field with the "ownership" bits last. */ @@ -1308,15 +1269,9 @@ /* Non-x86 Todo: explicitly flush cache lines here. */ - /* - * Wake the potentially-idle transmit channel unless errors are - * pending (the ISR must sort them out first). - */ - intr_status = get_intr_status(dev); - if ((intr_status & IntrTxErrSummary) == 0) { - writeb(readb(dev->base_addr + ChipCmd1) | Cmd1TxDemand, - dev->base_addr + ChipCmd1); - } + /* Wake the potentially-idle transmit channel */ + writeb(readb(ioaddr + ChipCmd1) | Cmd1TxDemand, + ioaddr + ChipCmd1); IOSYNC; if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN) @@ -1639,15 +1594,8 @@ spin_lock(&rp->lock); - if (intr_status & (IntrLinkChange)) { - rhine_check_duplex(dev); - if (debug) - printk(KERN_ERR "%s: MII status changed: " - "Autonegotiation advertising %4.4x partner " - "%4.4x.\n", dev->name, - mdio_read(dev, rp->mii_if.phy_id, MII_ADVERTISE), - mdio_read(dev, rp->mii_if.phy_id, MII_LPA)); - } + if (intr_status & IntrLinkChange) + rhine_check_media(dev, 0); if (intr_status & IntrStatsMax) { rp->stats.rx_crc_errors += readw(ioaddr + RxCRCErrs); rp->stats.rx_missed_errors += readw(ioaddr + RxMissed); @@ -1839,8 +1786,6 @@ long ioaddr = dev->base_addr; struct rhine_private *rp = netdev_priv(dev); - del_timer_sync(&rp->timer); - spin_lock_irq(&rp->lock); netif_stop_queue(dev); From rl@hellgate.ch Tue Jun 15 10:50:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 10:50:27 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FHoBgi026205 for ; Tue, 15 Jun 2004 10:50:13 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A68003EA279; Tue, 15 Jun 2004 17:49:58 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 5583421F343; Tue, 15 Jun 2004 19:49:56 +0200 (CEST) Date: Tue, 15 Jun 2004 19:49:56 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [8/9][PATCH 2.6] Small fixes and clean-up Message-ID: <20040615174956.GA11359@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 8069 Lines: 310 Bump driver version to mark recent major changes in driver code. Remove backoff parameter. The reason it was once introduced is gone. Continue to go with EEPROM default for now, will hard-wire IEEE backoff algorithm instead (later). Rhine-I needs extra time to recuperate from chip reset before EEPROM reload. Add Rhine model identification. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -125,11 +125,16 @@ LK1.1.19 (Roger Luethi) - Increase Tx threshold for unspecified errors + LK1.2.0-2.6 (Roger Luethi) + - Massive clean-up + - Rewrite PHY, media handling (remove options, full_duplex, backoff) + - Fix Tx engine race for good + */ #define DRV_NAME "via-rhine" -#define DRV_VERSION "1.1.20-2.6" -#define DRV_RELDATE "May-23-2004" +#define DRV_VERSION "1.2.0-2.6" +#define DRV_RELDATE "June-10-2004" /* A few user-configurable values. @@ -142,9 +147,6 @@ Setting to > 1518 effectively disables this feature. */ static int rx_copybreak; -/* Select a backoff algorithm (Ethernet capture effect) */ -static int backoff; - /* * In case you are looking for 'options[]' or 'full_duplex[]', they * are gone. Use ethtool(8) instead. @@ -207,9 +209,6 @@ static char version[] __devinitdata = KERN_INFO DRV_NAME ".c:v1.10-LK" DRV_VERSION " " DRV_RELDATE " Written by Donald Becker\n"; -static char shortname[] = DRV_NAME; - - /* This driver was written to use PCI memory space. Some early versions of the Rhine may only work correctly with I/O space accesses. */ #ifdef CONFIG_VIA_RHINE_MMIO @@ -236,11 +235,9 @@ MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM(debug, "i"); MODULE_PARM(rx_copybreak, "i"); -MODULE_PARM(backoff, "i"); MODULE_PARM_DESC(max_interrupt_work, "VIA Rhine maximum events handled per interrupt"); MODULE_PARM_DESC(debug, "VIA Rhine debug level (0-7)"); MODULE_PARM_DESC(rx_copybreak, "VIA Rhine copy breakpoint for copy-only-tiny-frames"); -MODULE_PARM_DESC(backoff, "VIA Rhine: Bits 0-3: backoff algorithm"); /* Theory of Operation @@ -343,17 +340,18 @@ enum rhine_revs { VT86C100A = 0x00, + VTunknown0 = 0x20, VT6102 = 0x40, VT8231 = 0x50, /* Integrated MAC */ VT8233 = 0x60, /* Integrated MAC */ VT8235 = 0x74, /* Integrated MAC */ VT8237 = 0x78, /* Integrated MAC */ - VTunknown0 = 0x7C, + VTunknown1 = 0x7C, VT6105 = 0x80, VT6105_B0 = 0x83, VT6105L = 0x8A, VT6107 = 0x8C, - VTunknown1 = 0x8E, + VTunknown2 = 0x8E, VT6105M = 0x90, }; @@ -609,7 +607,7 @@ /* * Loads bytes 0x00-0x05, 0x6E-0x6F, 0x78-0x7B from EEPROM - * (plus 0x6C for Rhine I/II) + * (plus 0x6C for Rhine-I/II) */ static void __devinit rhine_reload_eeprom(long pioaddr, struct net_device *dev) { @@ -645,9 +643,15 @@ static void rhine_hw_init(struct net_device *dev, long pioaddr) { + struct rhine_private *rp = netdev_priv(dev); + /* Reset the chip to erase previous misconfiguration. */ rhine_chip_reset(dev); + /* Rhine-I needs extra time to recuperate before EEPROM reload */ + if (rp->quirks & rqRhineI) + msleep(5); + /* Reload EEPROM controlled bytes cleared by soft reset */ rhine_reload_eeprom(pioaddr, dev); } @@ -660,12 +664,11 @@ int i, rc; u8 pci_rev; u32 quirks; - static int card_idx = -1; long pioaddr; long memaddr; long ioaddr; int io_size, phy_id; - const char *name; + const char *name, *mname; /* when built into the kernel, we only print version if device is found */ #ifndef MODULE @@ -678,22 +681,43 @@ io_size = 256; phy_id = 0; - if (pci_rev < VT6102) { + quirks = 0; + name = "Rhine"; + mname = "unknown"; + if (pci_rev < VTunknown0) { quirks = rqRhineI; io_size = 128; - name = "VT86C100A Rhine"; + mname = "VT86C100A"; } - else { + else if (pci_rev >= VT6102) { quirks = rqWOL | rqForceReset; if (pci_rev < VT6105) { name = "Rhine II"; quirks |= rqStatusWBRace; /* Rhine-II exclusive */ + if (pci_rev < VT8231) + mname = "VT6102"; + else if (pci_rev < VT8233) + mname = "VT8231"; + else if (pci_rev < VT8235) + mname = "VT8233"; + else if (pci_rev < VT8237) + mname = "VT8235"; + else if (pci_rev < VTunknown1) + mname = "VT8237"; } else { name = "Rhine III"; phy_id = 1; /* Integrated PHY, phy_id fixed to 1 */ if (pci_rev >= VT6105_B0) quirks |= rq6patterns; + if (pci_rev < VT6105L) + mname = "VT6105"; + else if (pci_rev < VT6107) + mname = "VT6105L"; + else if (pci_rev < VT6105M) + mname = "VT6107"; + else if (pci_rev >= VT6105M) + mname = "Management Adapter VT6105M"; } } @@ -722,17 +746,16 @@ pci_set_master(pdev); - dev = alloc_etherdev(sizeof(*rp)); - if (dev == NULL) { + dev = alloc_etherdev(sizeof(struct rhine_private)); + if (!dev) { rc = -ENOMEM; - printk(KERN_ERR "init_ethernet failed for card #%d\n", - card_idx); + printk(KERN_ERR "alloc_etherdev failed\n"); goto err_out; } SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - rc = pci_request_regions(pdev, shortname); + rc = pci_request_regions(pdev, DRV_NAME); if (rc) goto err_out_free_netdev; @@ -768,9 +791,8 @@ rp = netdev_priv(dev); rp->quirks = quirks; + /* Get chip registers into a sane state */ rhine_power_init(dev); - - /* Reset the chip to erase previous misconfiguration. */ rhine_hw_init(dev, pioaddr); for (i = 0; i < 6; i++) @@ -778,16 +800,11 @@ if (!is_valid_ether_addr(dev->dev_addr)) { rc = -EIO; - printk(KERN_ERR "Invalid MAC address for card #%d\n", card_idx); + printk(KERN_ERR "Invalid MAC address\n"); goto err_out_unmap; } - /* Select backoff algorithm */ - if (backoff) - writeb(readb(ioaddr + ConfigD) & (0xF0 | backoff), - ioaddr + ConfigD); - - /* For Rhine I/II, phy_id is loaded from EEPROM */ + /* For Rhine-I/II, phy_id is loaded from EEPROM */ if (!phy_id) phy_id = readb(ioaddr + 0x6C); @@ -822,8 +839,8 @@ if (rc) goto err_out_unmap; - printk(KERN_INFO "%s: VIA %s at 0x%lx, ", - dev->name, name, + printk(KERN_INFO "%s: VIA %s (%s) at 0x%lx, ", + dev->name, name, mname, #ifdef USE_MMIO memaddr #else @@ -1070,7 +1087,7 @@ IntrPCIErr | IntrStatsMax | IntrLinkChange, ioaddr + IntrEnable); - writew(CmdStart|CmdTxOn|CmdRxOn|(Cmd1NoTxPoll << 8), + writew(CmdStart | CmdTxOn | CmdRxOn | (Cmd1NoTxPoll << 8), ioaddr + ChipCmd); rhine_check_media(dev, 1); } @@ -1142,7 +1159,7 @@ writeb(phy_id, ioaddr + MIIPhyAddr); writeb(regnum, ioaddr + MIIRegAddr); writew(value, ioaddr + MIIData); - writeb(0x20, ioaddr + MIICmd); /* Trigger write. */ + writeb(0x20, ioaddr + MIICmd); /* Trigger write */ RHINE_WAIT_FOR(!(readb(ioaddr + MIICmd) & 0x20)); rhine_enable_linkmon(ioaddr); @@ -1152,20 +1169,20 @@ { struct rhine_private *rp = netdev_priv(dev); long ioaddr = dev->base_addr; - int i; + int rc; - i = request_irq(rp->pdev->irq, &rhine_interrupt, SA_SHIRQ, dev->name, + rc = request_irq(rp->pdev->irq, &rhine_interrupt, SA_SHIRQ, dev->name, dev); - if (i) - return i; + if (rc) + return rc; if (debug > 1) printk(KERN_DEBUG "%s: rhine_open() irq %d.\n", dev->name, rp->pdev->irq); - i = alloc_ring(dev); - if (i) - return i; + rc = alloc_ring(dev); + if (rc) + return rc; alloc_rbufs(dev); alloc_tbufs(dev); rhine_chip_reset(dev); @@ -1482,10 +1499,6 @@ rp->rx_buf_sz, PCI_DMA_FROMDEVICE); - /* *_IP_COPYSUM isn't defined anywhere and - eth_copy_and_sum is memcpy for all archs so - this is kind of pointless right now - ... or? */ eth_copy_and_sum(skb, rp->rx_skbuff[entry]->tail, pkt_len, 0); @@ -1574,7 +1587,6 @@ ioaddr + ChipCmd); writeb(readb(ioaddr + ChipCmd1) | Cmd1TxDemand, ioaddr + ChipCmd1); - IOSYNC; } else { @@ -1834,7 +1846,7 @@ static struct pci_driver rhine_driver = { - .name = "via-rhine", + .name = DRV_NAME, .id_table = rhine_pci_tbl, .probe = rhine_init_one, .remove = __devexit_p(rhine_remove_one), From rl@hellgate.ch Tue Jun 15 10:50:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 10:51:26 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FHoHgi026252 for ; Tue, 15 Jun 2004 10:50:17 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C001FCA77; Tue, 15 Jun 2004 17:50:04 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 98B8621F343; Tue, 15 Jun 2004 19:50:03 +0200 (CEST) Date: Tue, 15 Jun 2004 19:50:03 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [9/9][PATCH 2.6] Add WOL support Message-ID: <20040615175003.GA11382@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 5519 Lines: 209 Add rhine_shutdown callback to prepare Rhine power registers for shutdown. Add rhine_get_wol/rhine_set_wol for ethtool ioctl. Signed-off-by: Roger Luethi --- 2.6-mm/drivers/net/via-rhine.c.orig 2004-06-15 18:34:21.000000000 +0200 +++ 2.6-mm/drivers/net/via-rhine.c 2004-06-15 18:36:12.000000000 +0200 @@ -394,8 +394,8 @@ ConfigA=0x78, ConfigB=0x79, ConfigC=0x7A, ConfigD=0x7B, RxMissed=0x7C, RxCRCErrs=0x7E, MiscCmd=0x81, StickyHW=0x83, IntrStatus2=0x84, - WOLcrSet=0xA0, WOLcrClr=0xA4, WOLcrClr1=0xA6, - WOLcgClr=0xA7, + WOLcrSet=0xA0, PwcfgSet=0xA1, WOLcgSet=0xA3, WOLcrClr=0xA4, + WOLcrClr1=0xA6, WOLcgClr=0xA7, PwrcsrSet=0xA8, PwrcsrSet1=0xA9, PwrcsrClr=0xAC, PwrcsrClr1=0xAD, }; @@ -427,6 +427,15 @@ IntrTxErrSummary=0x082218, }; +/* Bits in WOLcrSet/WOLcrClr and PwrcsrSet/PwrcsrClr */ +enum wol_bits { + WOLucast = 0x10, + WOLmagic = 0x20, + WOLbmcast = 0x30, + WOLlnkon = 0x40, + WOLlnkoff = 0x80, +}; + /* The Rx and Tx buffer descriptors. */ struct rx_desc { s32 rx_status; @@ -491,8 +500,8 @@ unsigned int cur_rx, dirty_rx; /* Producer/consumer ring indices */ unsigned int cur_tx, dirty_tx; unsigned int rx_buf_sz; /* Based on MTU+slack. */ + u8 wolopts; - /* These values are keep track of the transceiver/media in use. */ u8 tx_thresh, rx_thresh; struct mii_if_info mii_if; @@ -512,6 +521,7 @@ static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); static struct ethtool_ops netdev_ethtool_ops; static int rhine_close(struct net_device *dev); +static void rhine_shutdown (struct device *gdev); #define RHINE_WAIT_FOR(condition) do { \ int i=1024; \ @@ -537,12 +547,13 @@ /* * Get power related registers into sane state. - * Returns content of power-event (WOL) registers. + * Notify user about past WOL event. */ static void rhine_power_init(struct net_device *dev) { long ioaddr = dev->base_addr; struct rhine_private *rp = netdev_priv(dev); + u16 wolstat; if (rp->quirks & rqWOL) { /* Make sure chip is in power state D0 */ @@ -557,10 +568,40 @@ if (rp->quirks & rq6patterns) writeb(0x03, ioaddr + WOLcrClr1); + /* Save power-event status bits */ + wolstat = readb(ioaddr + PwrcsrSet); + if (rp->quirks & rq6patterns) + wolstat |= (readb(ioaddr + PwrcsrSet1) & 0x03) << 8; + /* Clear power-event status bits */ writeb(0xFF, ioaddr + PwrcsrClr); if (rp->quirks & rq6patterns) writeb(0x03, ioaddr + PwrcsrClr1); + + if (wolstat) { + char *reason; + switch (wolstat) { + case WOLmagic: + reason = "Magic packet"; + break; + case WOLlnkon: + reason = "Link went up"; + break; + case WOLlnkoff: + reason = "Link went down"; + break; + case WOLucast: + reason = "Unicast packet"; + break; + case WOLbmcast: + reason = "Multicast/broadcast packet"; + break; + default: + reason = "Unknown"; + } + printk("%s: Woke system up. Reason: %s.\n", + DRV_NAME, reason); + } } } @@ -1766,6 +1807,39 @@ debug = value; } +static void rhine_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct rhine_private *rp = netdev_priv(dev); + + if (!(rp->quirks & rqWOL)) + return; + + spin_lock_irq(&rp->lock); + wol->supported = WAKE_PHY | WAKE_MAGIC | + WAKE_UCAST | WAKE_MCAST | WAKE_BCAST; /* Untested */ + wol->wolopts = rp->wolopts; + spin_unlock_irq(&rp->lock); +} + +static int rhine_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct rhine_private *rp = netdev_priv(dev); + u32 support = WAKE_PHY | WAKE_MAGIC | + WAKE_UCAST | WAKE_MCAST | WAKE_BCAST; /* Untested */ + + if (!(rp->quirks & rqWOL)) + return -EINVAL; + + if (wol->wolopts & ~support) + return -EINVAL; + + spin_lock_irq(&rp->lock); + rp->wolopts = wol->wolopts; + spin_unlock_irq(&rp->lock); + + return 0; +} + static struct ethtool_ops netdev_ethtool_ops = { .get_drvinfo = netdev_get_drvinfo, .get_settings = netdev_get_settings, @@ -1774,6 +1848,8 @@ .get_link = netdev_get_link, .get_msglevel = netdev_get_msglevel, .set_msglevel = netdev_set_msglevel, + .get_wol = rhine_get_wol, + .set_wol = rhine_set_wol, .get_sg = ethtool_op_get_sg, .get_tx_csum = ethtool_op_get_tx_csum, }; @@ -1844,12 +1920,51 @@ pci_set_drvdata(pdev, NULL); } +static void rhine_shutdown (struct device *gendev) +{ + struct pci_dev *pdev = to_pci_dev(gendev); + struct net_device *dev = pci_get_drvdata(pdev); + struct rhine_private *rp = netdev_priv(dev); + + long ioaddr = dev->base_addr; + + rhine_power_init(dev); + + /* Make sure we use pattern 0, 1 and not 4, 5 */ + if (rp->quirks & rq6patterns) + writeb(0x04, ioaddr + 0xA7); + + if (rp->wolopts & WAKE_MAGIC) + writeb(WOLmagic, ioaddr + WOLcrSet); + + if (rp->wolopts & (WAKE_BCAST|WAKE_MCAST)) + writeb(WOLbmcast, ioaddr + WOLcgSet); + + if (rp->wolopts & WAKE_PHY) + writeb(WOLlnkon | WOLlnkoff, ioaddr + WOLcrSet); + + if (rp->wolopts & WAKE_UCAST) + writeb(WOLucast, ioaddr + WOLcrSet); + + /* Enable legacy WOL (for old motherboards) */ + writeb(0x01, ioaddr + PwcfgSet); + writeb(readb(ioaddr + StickyHW) | 0x04, ioaddr + StickyHW); + + /* Hit power state D3 (sleep) */ + writeb(readb(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW); + + /* TODO: Check use of pci_enable_wake() */ + +} static struct pci_driver rhine_driver = { .name = DRV_NAME, .id_table = rhine_pci_tbl, .probe = rhine_init_one, .remove = __devexit_p(rhine_remove_one), + .driver = { + .shutdown = rhine_shutdown, + } }; From christopherc@team.outblaze.com Tue Jun 15 11:03:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 11:03:25 -0700 (PDT) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FI3Fgi027474 for ; Tue, 15 Jun 2004 11:03:18 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 63A0F37AF2 for ; Tue, 15 Jun 2004 18:03:14 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id 9125116DD96 for ; Tue, 15 Jun 2004 18:03:13 +0000 (GMT) Received: (qmail 7322 invoked from network); 15 Jun 2004 18:03:11 -0000 Received: from unknown (HELO ?192.168.1.17?) (christopherc@team.outblaze.com@202.81.246.192) by smtp1.hk1.outblaze.com with SMTP; 15 Jun 2004 18:03:11 -0000 Message-ID: <40CF3A35.3070906@outblaze.com> Date: Wed, 16 Jun 2004 02:04:37 +0800 From: Christopher Chan User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Chan Cc: Scott Feldman , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] e100: use NAPI mode all the time References: <40C58CA2.4090107@outblaze.com> In-Reply-To: <40C58CA2.4090107@outblaze.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.2-5; VAE: 6.25.0.62; VDF: 6.25.0.96; host: corpmail.outblaze.com) X-archive-position: 5950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 2055 Lines: 49 Christopher Chan wrote: > Scott Feldman wrote: > >> I see no reason to keep the non-NAPI option for e100. This patch removes >> the CONFIG_E100_NAPI option and puts the driver in NAPI mode all the >> time. >> Matches the way tg3 works. >> >> Unless someone has a really good reason to keep the non-NAPI mode, this >> should go in for 2.6.7. > > > I for one need to test 2.6.6 e100 with NAPI on. Under 2.6.3/4 I had > problems with NAPI mode turned on. Turning NAPI off and then also doing > > net.ipv4.tcp_max_syn_backlog = 2048 > net.ipv4.route.gc_thresh = 65536 > net.ipv4.route.max_size = 1048576 > > was the only way to keep the machines I run available via the network. > > I would get dst cache overflows and sometimes the kernel will log > garbled messages and when that happens the box requires a reboot. > KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1632) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1568) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1632) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1568) printk: 4253 messages suppressed. dst cache overflow KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1632) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1568) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1632) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1568) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1632) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1568) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1632) I get loads of this now for the only box that I have NAPI enabled on the e100 driver. This is on a 2.6.6 kernel. From brazilnut@us.ibm.com Tue Jun 15 11:55:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 11:55:59 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FItkgi029591 for ; Tue, 15 Jun 2004 11:55:53 -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.2) with ESMTP id i5FItakw693158; Tue, 15 Jun 2004 14:55:36 -0400 Received: from localhost.localdomain (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FIueP0114230; Tue, 15 Jun 2004 14:56:40 -0400 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5FIqOh20749; Tue, 15 Jun 2004 11:52:24 -0700 From: Don Fry Message-Id: <200406151852.i5FIqOh20749@localhost.localdomain> Subject: [PATCH 1 2.6.7-rc3-bk6] pcnet32: discard oversize rx packets To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 15 Jun 2004 11:52:24 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5951 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: 1617 Lines: 47 This patch will discard received frames that are larger than one buffer. This has been tested on ia32 and ppc64 systems. Please also apply to 2.4.7 (with offset of -3), tested ia32. Signed-off by: brazilnut@us.ibm.com --- linux-2.6.7-rc3-bk6/drivers/net/orig.pcnet32.c Mon Jun 14 12:19:09 2004 +++ linux-2.6.7-rc3-bk6/drivers/net/pcnet32.c Tue Jun 15 09:36:43 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30c" -#define DRV_RELDATE "05.25.2004" +#define DRV_VERSION "1.30d" +#define DRV_RELDATE "06.01.2004" #define PFX DRV_NAME ": " static const char *version = @@ -245,6 +245,7 @@ static int full_duplex[MAX_UNITS]; * v1.30b 24 May 2004 Don Fry fix bogus tx carrier errors with 79c973, * assisted by Bruce Penrod . * v1.30c 25 May 2004 Don Fry added netif_wake_queue after pcnet32_restart. + * v1.30d 01 Jun 2004 Don Fry discard oversize rx packets. */ @@ -1907,7 +1908,13 @@ pcnet32_rx(struct net_device *dev) short pkt_len = (le32_to_cpu(lp->rx_ring[entry].msg_length) & 0xfff)-4; struct sk_buff *skb; - if (pkt_len < 60) { + /* Discard oversize frames. */ + if (unlikely(pkt_len > PKT_BUF_SZ - 2)) { + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: Impossible packet size %d!\n", + dev->name, pkt_len); + lp->stats.rx_errors++; + } else if (pkt_len < 60) { if (netif_msg_rx_err(lp)) printk(KERN_ERR "%s: Runt packet!\n", dev->name); lp->stats.rx_errors++; -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Jun 15 12:05:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 12:05:10 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FJ54gi030311 for ; Tue, 15 Jun 2004 12:05:04 -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.2) with ESMTP id i5FJ4ukw413100; Tue, 15 Jun 2004 15:04:56 -0400 Received: from localhost.localdomain (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FJ60P0147164; Tue, 15 Jun 2004 15:06:01 -0400 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5FJ1j820768; Tue, 15 Jun 2004 12:01:45 -0700 From: Don Fry Message-Id: <200406151901.i5FJ1j820768@localhost.localdomain> Subject: [PATCH 2 2.6.7-rc3-bk6] pcnet32: recover after rx hang. To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 15 Jun 2004 12:01:45 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5952 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: 4750 Lines: 136 This patch fixes a receive hang that occasionally occurs after a Tx FIFO underrun. The receive dma remains in a hung state sometimes. The transmit operations continue to occur, but no receive activity. This was reproduced on several ppc64 systems and the fix has been verified there. The patch has been tested as well on an ia32 system, which did not experience the hang because it did not have fifo underruns, which is a preqrequisite for the hang. The memory barriers decreased the frequency of occurrence. The final change to reset the chip instead of just stopping it eliminated the last hangs. Please also apply against 2.4.7 (with offset of -1), tested ia32. Signed-off by: brazilnut@us.ibm.com --- linux-2.6.7-rc3-bk6/drivers/net/large.pcnet32.c Tue Jun 15 09:44:23 2004 +++ linux-2.6.7-rc3-bk6/drivers/net/pcnet32.c Tue Jun 15 10:00:17 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30d" -#define DRV_RELDATE "06.01.2004" +#define DRV_VERSION "1.30e" +#define DRV_RELDATE "06.11.2004" #define PFX DRV_NAME ": " static const char *version = @@ -246,6 +246,7 @@ static int full_duplex[MAX_UNITS]; * assisted by Bruce Penrod . * v1.30c 25 May 2004 Don Fry added netif_wake_queue after pcnet32_restart. * v1.30d 01 Jun 2004 Don Fry discard oversize rx packets. + * v1.30e 11 Jun 2004 Don Fry recover after fifo error and rx hang. */ @@ -1532,13 +1533,15 @@ pcnet32_purge_tx_ring(struct net_device int i; for (i = 0; i < TX_RING_SIZE; i++) { + lp->tx_ring[i].status = 0; /* CPU owns buffer */ + wmb(); /* Make sure adapter sees owner change */ if (lp->tx_skbuff[i]) { pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); dev_kfree_skb_any(lp->tx_skbuff[i]); - lp->tx_skbuff[i] = NULL; - lp->tx_dma_addr[i] = 0; } + lp->tx_skbuff[i] = NULL; + lp->tx_dma_addr[i] = 0; } } @@ -1567,21 +1570,23 @@ pcnet32_init_ring(struct net_device *dev skb_reserve (rx_skbuff, 2); } + rmb(); if (lp->rx_dma_addr[i] == 0) lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, rx_skbuff->tail, PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); lp->rx_ring[i].base = (u32)le32_to_cpu(lp->rx_dma_addr[i]); lp->rx_ring[i].buf_length = le16_to_cpu(2-PKT_BUF_SZ); + wmb(); /* Make sure owner changes after all others are visible */ lp->rx_ring[i].status = le16_to_cpu(0x8000); } /* The Tx buffer address is filled in as needed, but we do need to clear * the upper ownership bit. */ for (i = 0; i < TX_RING_SIZE; i++) { + lp->tx_ring[i].status = 0; /* CPU owns buffer */ + wmb(); /* Make sure adapter sees owner change */ lp->tx_ring[i].base = 0; - lp->tx_ring[i].status = 0; lp->tx_dma_addr[i] = 0; } - wmb(); /* Make sure all changes are visible */ lp->init_block.tlen_rlen = le16_to_cpu(TX_RING_LEN_BITS | RX_RING_LEN_BITS); for (i = 0; i < 6; i++) @@ -1590,9 +1595,14 @@ pcnet32_init_ring(struct net_device *dev offsetof(struct pcnet32_private, rx_ring)); lp->init_block.tx_ring = (u32)le32_to_cpu(lp->dma_addr + offsetof(struct pcnet32_private, tx_ring)); + wmb(); /* Make sure all changes are visible */ return 0; } +/* the pcnet32 has been issued a stop or reset. Wait for the stop bit + * then flush the pending transmit operations, re-initialize the ring, + * and tell the chip to initialize. + */ static void pcnet32_restart(struct net_device *dev, unsigned int csr0_bits) { @@ -1600,6 +1610,15 @@ pcnet32_restart(struct net_device *dev, unsigned long ioaddr = dev->base_addr; int i; + /* wait for stop */ + for (i=0; i<100; i++) + if (lp->a.read_csr(ioaddr, 0) & 0x0004) + break; + + if (i >= 100 && netif_msg_drv(lp)) + printk(KERN_ERR "%s: pcnet32_restart timed out waiting for stop.\n", + dev->name); + pcnet32_purge_tx_ring(dev); if (pcnet32_init_ring(dev)) return; @@ -1858,15 +1877,16 @@ pcnet32_interrupt(int irq, void *dev_id, } if (must_restart) { - /* stop the chip to clear the error condition, then restart */ - lp->a.write_csr (ioaddr, 0, 0x0004); + /* reset the chip to clear the error condition, then restart */ + lp->a.reset(ioaddr); + lp->a.write_csr(ioaddr, 4, 0x0915); pcnet32_restart(dev, 0x0002); netif_wake_queue(dev); } } - /* Clear any other interrupt, and set interrupt enable. */ - lp->a.write_csr (ioaddr, 0, 0x7940); + /* Set interrupt enable. */ + lp->a.write_csr (ioaddr, 0, 0x0040); lp->a.write_rap (ioaddr,rap); if (netif_msg_intr(lp)) -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Jun 15 12:09:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 12:09:50 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FJ9hgi030842 for ; Tue, 15 Jun 2004 12:09:44 -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 i5FJ9UeG333934; Tue, 15 Jun 2004 15:09:30 -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 i5FJAFaH091976; Tue, 15 Jun 2004 15:10:15 -0400 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5FJ6KK20782; Tue, 15 Jun 2004 12:06:20 -0700 From: Don Fry Message-Id: <200406151906.i5FJ6KK20782@localhost.localdomain> Subject: Re: [PATCH 1 2.6.7-rc3-bk6] pcnet32: discard oversize rx packets To: rddunlap@osdl.org (Randy.Dunlap) Date: Tue, 15 Jun 2004 12:06:19 -0700 (PDT) Cc: netdev@oss.sgi.com In-Reply-To: <20040615115829.46a6a674.rddunlap@osdl.org> from "Randy.Dunlap" at Jun 15, 2004 11:58:29 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5953 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: 502 Lines: 25 My preceeding two patches should have said: Signed-off-by: Don Fry Do I need to resubmit them? > | This patch will discard received frames that are larger than one buffer. > | This has been tested on ia32 and ppc64 systems. > | > | Please also apply to 2.4.7 (with offset of -3), tested ia32. > | > | Signed-off by: brazilnut@us.ibm.com > > Don- > > The requested format is: > > Signed-off-by: your name > > -- > ~Randy -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Jun 15 12:17:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 12:17:22 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FJH9gi031381 for ; Tue, 15 Jun 2004 12:17:15 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5FJGtnh615322; Tue, 15 Jun 2004 15:16:55 -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 i5FJHVaH113444; Tue, 15 Jun 2004 15:17:31 -0400 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5FJDZJ20805; Tue, 15 Jun 2004 12:13:35 -0700 From: Don Fry Message-Id: <200406151913.i5FJDZJ20805@localhost.localdomain> Subject: Re-send [PATCH 2 2.6.7-rc3-bk6] pcnet32: recover after rx hang. To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 15 Jun 2004 12:13:35 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5954 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: 2117 Lines: 55 This patch fixes a receive hang that occasionally occurs after a Tx FIFO underrun. The receive dma remains in a hung state sometimes. The transmit operations continue to occur, but no receive activity. This was reproduced on several ppc64 systems and the fix has been verified there. The patch has been tested as well on an ia32 system, which did not experience the hang because it did not have fifo underruns, which is a preqrequisite for the hang. The memory barriers decreased the frequency of occurrence. The final change to reset the chip instead of just stopping it eliminated the last hangs. Please also apply against 2.4.27 (with offset of -1), tested ia32. Signed-off-by: Don Fry --- linux-2.6.7-rc3-bk6/drivers/net/orig.pcnet32.c Mon Jun 14 12:19:09 2004 +++ linux-2.6.7-rc3-bk6/drivers/net/pcnet32.c Tue Jun 15 09:36:43 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30c" -#define DRV_RELDATE "05.25.2004" +#define DRV_VERSION "1.30d" +#define DRV_RELDATE "06.01.2004" #define PFX DRV_NAME ": " static const char *version = @@ -245,6 +245,7 @@ static int full_duplex[MAX_UNITS]; * v1.30b 24 May 2004 Don Fry fix bogus tx carrier errors with 79c973, * assisted by Bruce Penrod . * v1.30c 25 May 2004 Don Fry added netif_wake_queue after pcnet32_restart. + * v1.30d 01 Jun 2004 Don Fry discard oversize rx packets. */ @@ -1907,7 +1908,13 @@ pcnet32_rx(struct net_device *dev) short pkt_len = (le32_to_cpu(lp->rx_ring[entry].msg_length) & 0xfff)-4; struct sk_buff *skb; - if (pkt_len < 60) { + /* Discard oversize frames. */ + if (unlikely(pkt_len > PKT_BUF_SZ - 2)) { + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: Impossible packet size %d!\n", + dev->name, pkt_len); + lp->stats.rx_errors++; + } else if (pkt_len < 60) { if (netif_msg_rx_err(lp)) printk(KERN_ERR "%s: Runt packet!\n", dev->name); lp->stats.rx_errors++; -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Jun 15 13:04:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 13:04:20 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FK49gi003849 for ; Tue, 15 Jun 2004 13:04:17 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5FK3wnh266996; Tue, 15 Jun 2004 16:03:58 -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 i5FK4gaH123696; Tue, 15 Jun 2004 16:04:42 -0400 Received: (from donf@localhost) by localhost.localdomain (8.11.6/8.11.6) id i5FK0j721133; Tue, 15 Jun 2004 13:00:45 -0700 From: Don Fry Message-Id: <200406152000.i5FK0j721133@localhost.localdomain> Subject: too many errors To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 15 Jun 2004 13:00:45 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5955 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: 361 Lines: 13 I can't seem to do anything right today. The correct version of 2.4 is 2.4.27-pre5. I mixed the description and the contents of the re-send. Jeff, if you would like me to correctly send these two patches another day, let me know. If you could figure out what I meant instead of what I said, you're doing better than I. ;-) -- Don Fry brazilnut@us.ibm.com From P@draigBrady.com Tue Jun 15 13:14:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 13:14:42 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FKEcgi004540 for ; Tue, 15 Jun 2004 13:14:39 -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 i5FKEaOC026411 for ; Tue, 15 Jun 2004 21:14:36 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40CF58AC.2060802@draigBrady.com> Date: Tue, 15 Jun 2004 21:14:36 +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: netdev@oss.sgi.com Subject: flow control in e100 Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i5FKEaOC026411 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5FKEcgi004540 X-archive-position: 5956 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: 362 Lines: 18 Hi, I'm using the e100 V3.0.13, and I've a few questions regarding flow control. This logic is crying out for a comment... [config->fc_disable=0;] if(nic->mac >= mac_82558_D101_A4) { config->fc_disable = 0x1; /* 1=Tx fc off, 0=Tx fc on */ } Also how does one query set flow control? ethtool -[aA] doesn't seem to be supported. thanks, Pádraig. From shemminger@osdl.org Tue Jun 15 14:42:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 14:42:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FLgdgi009113 for ; Tue, 15 Jun 2004 14:42:39 -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 i5FLgRr16557; Tue, 15 Jun 2004 14:42:27 -0700 Date: Tue, 15 Jun 2004 14:42:27 -0700 From: Stephen Hemminger To: Alexander Viro , "David S. Miller" Cc: netdev@oss.sgi.com Subject: __user in atm.h Message-Id: <20040615144227.05d2b9fa@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: 5957 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: 609 Lines: 17 Recent Sparse fixes put __user in atm.h 'struct atmif_sioc' unfortunately, that structure gets used by tools that include atm.h as well (like iproute2), and in that environment __user is not defined. Usual fix is to include compiler.h to hide this breakage. diff -Nru a/include/linux/atm.h b/include/linux/atm.h --- a/include/linux/atm.h 2004-06-15 14:42:47 -07:00 +++ b/include/linux/atm.h 2004-06-15 14:42:47 -07:00 @@ -20,6 +20,7 @@ #include #include #endif +#include #include #include #include From rl@hellgate.ch Tue Jun 15 14:53:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 14:53:33 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FLrUgi009652 for ; Tue, 15 Jun 2004 14:53:30 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40A46A68003EA192; Tue, 15 Jun 2004 17:47:33 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id D01B321F343; Tue, 15 Jun 2004 19:47:32 +0200 (CEST) Date: Tue, 15 Jun 2004 19:47:32 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [0/9] via-rhine: Major surgery Message-ID: <20040615174732.GA10241@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 408 Lines: 11 This set of patches obsoletes all via-rhine patches for 2.6 that didn't make it into 2.6.7-rc3-mm2. Most notable changes: I rewrote the media, PHY, and link state handling and added WOL support for Rhine chips. Patches [1/9] and [2/9] are resends so you won't have to go hunt them down before trying the rest. These patches need review and testing, especially from people with WOL-capable hardware. Roger From chrisw@osdl.org Tue Jun 15 15:55:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 15:55:52 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FMtmgi011215 for ; Tue, 15 Jun 2004 15:55:49 -0700 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i5FMtgr29845; Tue, 15 Jun 2004 15:55:42 -0700 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id i5FMtfT09469; Tue, 15 Jun 2004 15:55:41 -0700 Date: Tue, 15 Jun 2004 15:55:41 -0700 From: Chris Wright To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH] ethtool_get_regs copy right number of bytes to user Message-ID: <20040615155541.Q21045@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 5959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 558 Lines: 17 If regs.len is smaller than reglen it's possible to copy more bytes out than the user asked for. Signed-off-by: Chris Wright ===== net/core/ethtool.c 1.14 vs edited ===== --- 1.14/net/core/ethtool.c 2004-06-02 14:54:28 -07:00 +++ edited/net/core/ethtool.c 2004-06-13 12:59:15 -07:00 @@ -157,7 +157,7 @@ if (copy_to_user(useraddr, ®s, sizeof(regs))) goto out; useraddr += offsetof(struct ethtool_regs, data); - if (copy_to_user(useraddr, regbuf, reglen)) + if (copy_to_user(useraddr, regbuf, regs.len)) goto out; ret = 0; From anton@ozlabs.org Tue Jun 15 16:37:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 16:37:32 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5FNbSgi015399 for ; Tue, 15 Jun 2004 16:37:28 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 6A1462BD3F; Wed, 16 Jun 2004 09:37:22 +1000 (EST) Date: Wed, 16 Jun 2004 09:34:23 +1000 From: Anton Blanchard To: "David S. Miller" Cc: sfeldma@pobox.com, netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, leonid.grossman@s2io.com Subject: Re: Allow IP header alignment to be overriden Message-ID: <20040615233423.GC3228@krispykreme> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> <1086939562.3657.10.camel@sfeldma-mobl2.dsl-verizon.net> <20040611142336.GE27672@krispykreme> <20040612111218.783f587d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040612111218.783f587d.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 5960 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: 5759 Lines: 170 > Yes. Please add a paragraph to that comment explaining what "unaligned > CPU cost" really means, ie. that the IP/TCP header members are going to > be accessed with alignment less than the types might require on a given > architecture. > > Then I'll apply this and we can start beating up the drivers. How does this look? The s2io, ixgb and e1000 drivers are converted. Anton ===== include/linux/skbuff.h 1.43 vs edited ===== --- 1.43/include/linux/skbuff.h Mon May 31 05:09:46 2004 +++ edited/include/linux/skbuff.h Wed Jun 16 08:13:57 2004 @@ -816,6 +816,30 @@ skb->tail += len; } +/* + * CPUs often take a performance hit when accessing unaligned memory + * locations. The actual performance hit varies, it can be small if the + * hardware handles it or large if we have to take an exception and fix it + * in software. + * + * Since an ethernet header is 14 bytes network drivers often end up with + * the IP header at an unaligned offset. The IP header can be aligned by + * shifting the start of the packet by 2 bytes. Drivers should do this + * with: + * + * skb_reserve(NET_IP_ALIGN); + * + * The downside to this alignment of the IP header is that the DMA is now + * unaligned. On some architectures the cost of an unaligned DMA is high + * and this cost outweighs the gains made by aligning the IP header. + * + * Since this trade off varies between architectures, we allow NET_IP_ALIGN + * to be overridden. + */ +#ifndef NET_IP_ALIGN +#define NET_IP_ALIGN 2 +#endif + extern int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc); static inline void __skb_trim(struct sk_buff *skb, unsigned int lenj ===== include/asm-ppc64/system.h 1.28 vs edited ===== --- 1.28/include/asm-ppc64/system.h Fri May 21 17:50:12 2004 +++ edited/include/asm-ppc64/system.h Wed Jun 16 08:15:28 2004 @@ -277,5 +277,14 @@ (unsigned long)_n_, sizeof(*(ptr))); \ }) +/* + * We handle most unaligned accesses in hardware. On the other hand + * unaligned DMA can be very expensive on some ppc64 IO chips (it does + * powers of 2 writes until it reaches sufficient alignment). + * + * Based on this we disable the IP header alignment in network drivers. + */ +#define NET_IP_ALIGN 0 + #endif /* __KERNEL__ */ #endif ===== drivers/net/s2io.c 1.5 vs edited ===== --- 1.5/drivers/net/s2io.c Fri Jun 4 12:00:15 2004 +++ edited/drivers/net/s2io.c Wed Jun 16 08:18:15 2004 @@ -1425,13 +1425,13 @@ goto end; } - skb = dev_alloc_skb(size + HEADER_ALIGN_LAYER_3); + skb = dev_alloc_skb(size + NET_IP_ALIGN); if (!skb) { DBG_PRINT(ERR_DBG, "%s: Out of ", dev->name); DBG_PRINT(ERR_DBG, "memory to allocate SKBs\n"); return -ENOMEM; } - skb_reserve(skb, HEADER_ALIGN_LAYER_3); + skb_reserve(skb, NET_IP_ALIGN); memset(rxdp, 0, sizeof(RxD_t)); rxdp->Buffer0_ptr = pci_map_single (nic->pdev, skb->data, size, PCI_DMA_FROMDEVICE); ===== drivers/net/s2io.h 1.4 vs edited ===== --- 1.4/drivers/net/s2io.h Mon May 31 17:46:35 2004 +++ edited/drivers/net/s2io.h Wed Jun 16 08:17:23 2004 @@ -411,7 +411,6 @@ #define HEADER_802_2_SIZE 3 #define HEADER_SNAP_SIZE 5 #define HEADER_VLAN_SIZE 4 -#define HEADER_ALIGN_LAYER_3 2 #define MIN_MTU 46 #define MAX_PYLD 1500 ===== drivers/net/e1000/e1000_ethtool.c 1.45 vs edited ===== --- 1.45/drivers/net/e1000/e1000_ethtool.c Fri May 28 06:59:25 2004 +++ edited/drivers/net/e1000/e1000_ethtool.c Wed Jun 16 08:34:38 2004 @@ -1004,11 +1004,12 @@ struct e1000_rx_desc *rx_desc = E1000_RX_DESC(*rxdr, i); struct sk_buff *skb; - if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + 2, GFP_KERNEL))) { + if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, + GFP_KERNEL))) { ret_val = 6; goto err_nomem; } - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); rxdr->buffer_info[i].skb = skb; rxdr->buffer_info[i].length = E1000_RXBUFFER_2048; rxdr->buffer_info[i].dma = ===== drivers/net/e1000/e1000_main.c 1.118 vs edited ===== --- 1.118/drivers/net/e1000/e1000_main.c Fri Jun 4 10:59:04 2004 +++ edited/drivers/net/e1000/e1000_main.c Wed Jun 16 08:36:58 2004 @@ -2367,7 +2367,6 @@ struct e1000_rx_desc *rx_desc; struct e1000_buffer *buffer_info; struct sk_buff *skb; - int reserve_len = 2; unsigned int i; i = rx_ring->next_to_use; @@ -2376,7 +2375,7 @@ while(!buffer_info->skb) { rx_desc = E1000_RX_DESC(*rx_ring, i); - skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); + skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); if(!skb) { /* Better luck next round */ @@ -2387,7 +2386,7 @@ * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed */ - skb_reserve(skb, reserve_len); + skb_reserve(skb, NET_IP_ALIGN); skb->dev = netdev; ===== drivers/net/ixgb/ixgb_main.c 1.13 vs edited ===== --- 1.13/drivers/net/ixgb/ixgb_main.c Tue Jun 1 10:01:23 2004 +++ edited/drivers/net/ixgb/ixgb_main.c Wed Jun 16 08:23:28 2004 @@ -1876,7 +1876,6 @@ struct ixgb_rx_desc *rx_desc; struct ixgb_buffer *buffer_info; struct sk_buff *skb; - int reserve_len = 2; unsigned int i; int num_group_tail_writes; long cleancount; @@ -1895,7 +1894,7 @@ while (--cleancount > 0) { rx_desc = IXGB_RX_DESC(*rx_ring, i); - skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); + skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); if (unlikely(!skb)) { /* Better luck next round */ @@ -1906,7 +1905,7 @@ * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed */ - skb_reserve(skb, reserve_len); + skb_reserve(skb, NET_IP_ALIGN); skb->dev = netdev; From mcgrof@studorgs.rutgers.edu Tue Jun 15 17:11:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 17:11:17 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G0BEgi016716 for ; Tue, 15 Jun 2004 17:11:15 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id D10C7F9D54; Tue, 15 Jun 2004 20:11:11 -0400 (EDT) Date: Tue, 15 Jun 2004 20:11:11 -0400 To: Margit Schubert-While Cc: prism54-devel@prism54.org, Netdev Subject: Re: [Prism54-devel] GUPD (Grand Unified Prism54 Driver) Open discussion Message-ID: <20040616001111.GK6253@ruslug.rutgers.edu> Mail-Followup-To: Margit Schubert-While , prism54-devel@prism54.org, Netdev References: <5.1.0.14.2.20040615143603.02a40b48@pop.t-online.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040615143603.02a40b48@pop.t-online.de> 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: 5961 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: 2183 Lines: 73 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 15, 2004 at 09:17:48PM +0200, Margit Schubert-While wrote: > As an experiment, I have just tried merging all source code for a > GUPD (Grand Unified Prism54 Driver) :-) > prism54.h - 1063 lines > prism54.c - 5583 lines > With everything defined static (data and functions), it works and > saves a chunk of generated code. >=20 > Is this something we should be looking at ? >=20 > Some points : > With this setup, we can move the driver up into net/wireless. > We get rid of the horrible prism include dependencies. > (All structures/defs are available to all routines) > Everything gets defined static allowing the compiler to produce > compact code. This, though, means that kernel stack traces are > less informative. (But, of course, we don't get oops'es in prism54 > do we ? :-) ) >=20 > OK Discuss. I like the idea, I think we should just time the change appropriately to alllow current work out there to get included / branched in. --- What's left / being worked on (near future)?=20 * WPA - PSK - I'm working on this, hope to have a patch this week for cvs t= esting. * WDS - Umm someone on the list had mentioned they had used WDS successfully and had some patches (?) Are you still alive? Are you still working on this? * ethtool support - Basic ethtool support is easy althought this can wait * Move verbose/debug printing to use netif_msg instead of our nasty ifdefs. No one is working on this yet though so it can wait. --- Anyone else working on anything for prism54 and would like us to wait for you before merging all into the proposed GUPD? Anyone disagree with this approach? Comments? PS: please CC netdev Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAz5Afat1JN+IKUl4RAsSHAJsG/ZbrUzDUkEEF2FibxBnRLuyFgwCgocDL FKTVO+DTbGmVfVD26OgBM8w= =Gx5I -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From mcgrof@studorgs.rutgers.edu Tue Jun 15 19:20:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 19:20:13 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G2K8gi020089 for ; Tue, 15 Jun 2004 19:20:10 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 685EFF98B1; Tue, 15 Jun 2004 22:20:08 -0400 (EDT) Date: Tue, 15 Jun 2004 22:20:08 -0400 To: Jeff Garzik Cc: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54] CVS -> bk tree update Message-ID: <20040616022008.GM6253@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="at6+YcpfzWZg/htY" Content-Disposition: inline In-Reply-To: <40CE2754.1020109@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: 5962 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: 1539 Lines: 51 --at6+YcpfzWZg/htY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 14, 2004 at 06:31:48PM -0400, Jeff Garzik wrote: > Luis R. Rodriguez wrote: > >Hey Jeff, > > > >was wondering what the status of the latest prism54 patches is. Did all > >go through cleanly, are we in-sync now? Are there patches you're still > >reviewing? >=20 >=20 > Check Andrew's -mm tree and see if there's anything missing. >=20 > Jeff Thanks Jeff. I did, and a diff of Andrew's -mm tree Vs our cvs tree 2.6.7-prism54 gives a 1898 line diff. This is excluding spaces, newlines, and tabbing and all of Andew's .orig, .rej's.=20 This time it's going to be a *real* pain to provide a changelog and split t= he diffs.. so can I just send you that 1898 line diff and then another for space changes? Everything has already been reviewed on the lists here... I promise this will be our last big patch too. I'll ask our team to send patches from now on to netdev after each ChangeLog entry, for more public review and to not loose sync of our trees. Let us know if you think we should do otherwise. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --at6+YcpfzWZg/htY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAz65Yat1JN+IKUl4RAsYhAJ9UkRve/oHwmnpoyNEytlqrRbm4CwCgo289 0z2OySyPiczVe6y+IIE01Yg= =j48N -----END PGP SIGNATURE----- --at6+YcpfzWZg/htY-- From davem@redhat.com Tue Jun 15 21:14:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 21:14:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G4Eagi025969 for ; Tue, 15 Jun 2004 21:14:37 -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 i5G4EWe1015992; Wed, 16 Jun 2004 00:14:32 -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 i5G4EW017792; Wed, 16 Jun 2004 00:14:32 -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 i5G4EFXT027929; Wed, 16 Jun 2004 00:14:15 -0400 Date: Tue, 15 Jun 2004 21:08:34 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [IPV6 2.4] UDPv6: checksum Message-Id: <20040615210834.2ddb9ed2.davem@redhat.com> In-Reply-To: <20040616.000449.48351036.yoshfuji@linux-ipv6.org> References: <20040616.000449.48351036.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 i5G4Eagi025969 X-archive-position: 5963 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: 256 Lines: 8 On Wed, 16 Jun 2004 00:04:49 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > We always need to check UDPv6 checksum because it is mandatory. > This patch is for 2.4. Both 2.4.x and 2.6.x versions applied, thanks a lot. From davem@redhat.com Tue Jun 15 21:15:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 21:15:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G4Ftgi026142 for ; Tue, 15 Jun 2004 21:15: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 i5G4Fse1016398; Wed, 16 Jun 2004 00:15: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 i5G4Fs018184; Wed, 16 Jun 2004 00:15: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 i5G4Fb7c028641; Wed, 16 Jun 2004 00:15:37 -0400 Date: Tue, 15 Jun 2004 21:09:56 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [2.4,IPV6] UDPv6: use udpv6_queue_rcv_skb(). Message-Id: <20040615210956.332632d2.davem@redhat.com> In-Reply-To: <20040616.001016.54016316.yoshfuji@linux-ipv6.org> References: <20040616.001016.54016316.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 i5G4Ftgi026142 X-archive-position: 5964 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: 245 Lines: 8 On Wed, 16 Jun 2004 00:10:16 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Use udpv6_queue_rcv_skb() instead of sock_queue_rcv_skb() > as we do in 2.6 for checksum, (ipsec and) statistics. Applied, thanks. From davem@redhat.com Tue Jun 15 21:41:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 21:41:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G4f3gi027161 for ; Tue, 15 Jun 2004 21:41:03 -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 i5G4f0e1021348; Wed, 16 Jun 2004 00:41: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 i5G4f0023223; Wed, 16 Jun 2004 00:41:00 -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 i5G4ehjo002009; Wed, 16 Jun 2004 00:40:44 -0400 Date: Tue, 15 Jun 2004 21:35:02 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: aviro@redhat.com, netdev@oss.sgi.com Subject: Re: __user in atm.h Message-Id: <20040615213502.6bc0c8dc.davem@redhat.com> In-Reply-To: <20040615144227.05d2b9fa@dell_ss3.pdx.osdl.net> References: <20040615144227.05d2b9fa@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5965 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: 26 Lines: 2 Applied, thanks Stephen. From davem@redhat.com Tue Jun 15 21:43:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 21:43:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G4hNgi027569 for ; Tue, 15 Jun 2004 21:43:24 -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 i5G4hMe1021774; Wed, 16 Jun 2004 00:43:22 -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 i5G4hM023704; Wed, 16 Jun 2004 00:43: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 i5G4h4n9002484; Wed, 16 Jun 2004 00:43:04 -0400 Date: Tue, 15 Jun 2004 21:37:23 -0700 From: "David S. Miller" To: Anton Blanchard Cc: sfeldma@pobox.com, netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, leonid.grossman@s2io.com Subject: Re: Allow IP header alignment to be overriden Message-Id: <20040615213723.21e825d0.davem@redhat.com> In-Reply-To: <20040615233423.GC3228@krispykreme> References: <20040611012727.GA27672@krispykreme> <20040610223549.5e9ad025.davem@redhat.com> <1086939562.3657.10.camel@sfeldma-mobl2.dsl-verizon.net> <20040611142336.GE27672@krispykreme> <20040612111218.783f587d.davem@redhat.com> <20040615233423.GC3228@krispykreme> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5966 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: 506 Lines: 15 On Wed, 16 Jun 2004 09:34:23 +1000 Anton Blanchard wrote: > > Yes. Please add a paragraph to that comment explaining what "unaligned > > CPU cost" really means, ie. that the IP/TCP header members are going to > > be accessed with alignment less than the types might require on a given > > architecture. > > > > Then I'll apply this and we can start beating up the drivers. > > How does this look? The s2io, ixgb and e1000 drivers are converted. Works for me, applied. Thanks Anton. From mcgrof@studorgs.rutgers.edu Tue Jun 15 22:11:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 22:11:09 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G5B3gi028442 for ; Tue, 15 Jun 2004 22:11:04 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 67E47F9D4D; Wed, 16 Jun 2004 01:11:03 -0400 (EDT) Date: Wed, 16 Jun 2004 01:11:03 -0400 To: Jeff Garzik Cc: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54] CVS -> bk tree update Message-ID: <20040616051103.GN6253@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> <20040616022008.GM6253@ruslug.rutgers.edu> <40CFBA24.7030307@pobox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pY3vCvL1qV+PayAL" Content-Disposition: inline In-Reply-To: <40CFBA24.7030307@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: 5967 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: 4092 Lines: 100 --pY3vCvL1qV+PayAL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 15, 2004 at 11:10:28PM -0400, Jeff Garzik wrote: > Luis R. Rodriguez wrote: > >Thanks Jeff. I did, and a diff of Andrew's -mm tree Vs our cvs tree > >2.6.7-prism54 gives a 1898 line diff. This is excluding spaces, > >newlines, and tabbing and all of Andew's .orig, .rej's.=20 > > > >This time it's going to be a *real* pain to provide a changelog and spli= t=20 > >the > >diffs.. so can I just send you that 1898 line diff and then another for > >space changes? Everything has already been reviewed on the lists here... > > > >I promise this will be our last big patch too. I'll ask our team > >to send patches from now on to netdev after each ChangeLog entry, for > >more public review and to not loose sync of our trees. Let us know if > >you think we should do otherwise. >=20 >=20 > Sorry, no. You knew that split-up patches would be needed, once the=20 > initial driver merge is complete (which was complete before the most=20 > recent series of 17 patches). Actually no. I wasn't aware of how netdev patches went upstream until the driver got in and our first set of patches got rejected. After the driver got in the kernel the first set of patches was just to get the kernel tree up to speed with what *really* was current in our cvs tree (remember Jean was the one who submitted the original patch). What occurred afterwards was more of a misunderstanding of what is acceptable and what is not for patches for network driver projects. I thought, since you had suggested to continue with the prism54 project, and submit a patch for our next release. No one on our dev team or=20 lists knew any better or didn't say much to make us think otherwise. > This is one of the big downsides to developing in CVS,=20 for the kernel since what's mainly used by mantainers is bitkeeper =20 > and it bites=20 > people again and again. CVS is used as a project repository, not *the linux kernel repository*. It = would seem to me reasonable though that if a project is doing a good job in making sure code gets tested, keeping a tight bugzilla, cvs daily updates, a detailed changelog, and viewcvs, that a big patch sent out to kernel mantainers for a new driver project release version would just be accepted. Apparantly not and *this* is what sucks about using CVS -- the fact these rules for small patches exist, and that the kernel uses a different versioning system. And that's it. > Linux kernel development relies on split-up patches for review, testing,= =20 > and narrowing down which patch in a series introduced a bug. There=20 > are real, engineering-related reasons we do things this way. Don't get me wrong... I love this. I think that because of this is why we have such a great kernel. The problem here was that there was miscommunication between you, Jean, and us. The patch shouldn't have been accepted to include the driver into the kernel until=20 our main project goals were completed. We then did not know the details=20 on followup procedures to update netdev drivers, nor were we told. We've learned our lesson the hard way. Oh well. Just please warn others submitting new drivers too -- submit until you think you only have small changes left, and also integrate the driver by verifying first with the=20 mantainers (warn about patch policy, etc). We'll just send patches for *every* CVS changelog entry from now on. This also just makes me want to just consider using bitkeeper. What benefit= s are there for our project, would we be able to get write access, and how else would procedures change for us? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --pY3vCvL1qV+PayAL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAz9Znat1JN+IKUl4RAuDLAJ0S0Lo2X6PxH3ipd0rdNlVmBHgUEQCcCfLr RuT3vZNziF6YKeErzylw/HI= =Ukft -----END PGP SIGNATURE----- --pY3vCvL1qV+PayAL-- From rl@hellgate.ch Tue Jun 15 23:25:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 23:25:57 -0700 (PDT) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G6PYgi030907 for ; Tue, 15 Jun 2004 23:25:35 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail2.bluewin.ch (Bluewin AG 7.0.028) id 40A46896003E8D64; Tue, 15 Jun 2004 17:48:39 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 77C0E21F343; Tue, 15 Jun 2004 19:48:39 +0200 (CEST) Date: Tue, 15 Jun 2004 19:48:39 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [3/9][PATCH 2.6] Remove lingering PHY special casing Message-ID: <20040615174839.GA11191@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5968 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 1595 Lines: 51 All this code is broken (e.g. unconditionally programs all PHYs as if they were the same model) and/or unused (IntrLinkChange never occurs with driver as is). Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -373,7 +373,6 @@ enum rhine_quirks { rqWOL = 0x0001, /* Wake-On-LAN support */ rqForceReset = 0x0002, - rqDavicomPhy = 0x0020, rq6patterns = 0x0040, /* 6 instead of 4 patterns for WOL */ rqStatusWBRace = 0x0080, /* Tx Status Writeback Error possible */ rqRhineI = 0x0100, /* See comment below */ @@ -698,7 +697,7 @@ io_size = 256; if (pci_rev < VT6102) { - quirks = rqRhineI | rqDavicomPhy; + quirks = rqRhineI; io_size = 128; name = "VT86C100A Rhine"; } @@ -1113,11 +1112,6 @@ writew(rp->chip_cmd, ioaddr + ChipCmd); rhine_check_duplex(dev); - - /* The LED outputs of various MII xcvrs should be configured. */ - /* For NS or Mison phys, turn on bit 1 in register 0x17 */ - mdio_write(dev, rp->phys[0], 0x17, mdio_read(dev, rp->phys[0], 0x17) | - 0x0001); } /* Read and write over the MII Management Data I/O (MDIO) interface. */ @@ -1692,12 +1686,7 @@ spin_lock(&rp->lock); if (intr_status & (IntrLinkChange)) { - if (readb(ioaddr + MIIStatus) & 0x02) { - /* Link failed, restart autonegotiation. */ - if (rp->quirks & rqRhineI) - mdio_write(dev, rp->phys[0], MII_BMCR, 0x3300); - } else - rhine_check_duplex(dev); + rhine_check_duplex(dev); if (debug) printk(KERN_ERR "%s: MII status changed: " "Autonegotiation advertising %4.4x partner " From davem@redhat.com Tue Jun 15 23:32:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 23:32:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G6W8gi031714 for ; Tue, 15 Jun 2004 23:32: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 i5G3PAe1006395; Tue, 15 Jun 2004 23:25: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 i5G3P9008491; Tue, 15 Jun 2004 23:25: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 i5G3OqP9017884; Tue, 15 Jun 2004 23:24:53 -0400 Date: Tue, 15 Jun 2004 20:19:12 -0700 From: "David S. Miller" To: bert hubert Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [DOCUMENTATION PATCH] Missing net sysctls, some fixed, rest flagged Message-Id: <20040615201912.691ffe35.davem@redhat.com> In-Reply-To: <20040609175242.GA13875@outpost.ds9a.nl> References: <20040609175242.GA13875@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5969 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: 4592 Lines: 144 Looks fine, I applied it with some minor changes as follows: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/15 20:20:25-07:00 ahu@ds9a.nl # [NET]: Update some sysctl documentation. # # I ran the following (crappy) script: # ... # In /proc/sys/ and found a host of undocumented sysctls. This patch documents # a number of them, and at least mentions the rest as 'TODO'. Please verify my # code-inspired documentation before applying! # # Signed-off-by: Bert Hubert # Signed-off-by: David S. Miller # # Documentation/networking/ip-sysctl.txt # 2004/06/15 20:19:32-07:00 ahu@ds9a.nl +57 -0 # [NET]: Update some sysctl documentation. # # I ran the following (crappy) script: # ... # In /proc/sys/ and found a host of undocumented sysctls. This patch documents # a number of them, and at least mentions the rest as 'TODO'. Please verify my # code-inspired documentation before applying! # # Signed-off-by: Bert Hubert # Signed-off-by: David S. Miller # # Documentation/filesystems/proc.txt # 2004/06/15 20:19:32-07:00 ahu@ds9a.nl +2 -1 # [NET]: Update some sysctl documentation. # # I ran the following (crappy) script: # ... # In /proc/sys/ and found a host of undocumented sysctls. This patch documents # a number of them, and at least mentions the rest as 'TODO'. Please verify my # code-inspired documentation before applying! # # Signed-off-by: Bert Hubert # Signed-off-by: David S. Miller # diff -Nru a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt --- a/Documentation/filesystems/proc.txt 2004-06-15 20:20:56 -07:00 +++ b/Documentation/filesystems/proc.txt 2004-06-15 20:20:56 -07:00 @@ -1640,7 +1640,8 @@ Writing to this file results in a flush of the routing cache. -gc_elastic, gc_interval, gc_min_interval, gc_tresh, gc_timeout +gc_elasticity, gc_interval, gc_min_interval, gc_tresh, gc_timeout, +gc_thresh, gc_thresh1, gc_thresh2, gc_thresh3 -------------------------------------------------------------- Values to control the frequency and behavior of the garbage collection diff -Nru a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt --- a/Documentation/networking/ip-sysctl.txt 2004-06-15 20:20:56 -07:00 +++ b/Documentation/networking/ip-sysctl.txt 2004-06-15 20:20:56 -07:00 @@ -17,6 +17,16 @@ Disable Path MTU Discovery. default FALSE +min_pmtu - INTEGER + default 562 - minimum discovered Path MTU + +mtu_expires - INTEGER + Time, in seconds, that cached PMTU information is kept. + +min_adv_mss - INTEGER + The advertised MSS depends on the first hop route MTU, but will + never be lower than this setting. + IP Fragmentation: ipfrag_high_thresh - INTEGER @@ -345,6 +355,19 @@ conections. Default: 7 + +tcp_frto - BOOLEAN + Enables F-RTO, an enhanced recovery algorithm for TCP retransmission + timeouts. It is particularly beneficial in wireless environments + where packet loss is typically due to random radio interference + rather than intermediate router congestion. + +somaxconn - INTEGER + Limit of TCP listen backlog, known in userspace as SOMAXCONN. + Defaults to 128 + +IP Variables: + ip_local_port_range - 2 INTEGERS Defines the local port range that is used by TCP and UDP to choose the local port. The first number is the first, the @@ -586,6 +609,19 @@ The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface} +app_solicit - INTEGER + The maximum number of probes to send to the user space ARP daemon + via netlink before dropping back to multicast probes (see + mcast_solicit). Defaults to 0. + +disable_policy - BOOLEAN + Disable IPSEC policy (SPD) for this interface + +disable_xfrm - BOOLEAN + Disable IPSEC encryption on this interface, whatever the policy + + + tag - INTEGER Allows you to write a number, which can be used as required. Default value is 0. @@ -803,5 +839,26 @@ 0 : disable this. Default: 1 + +UNDOCUMENTED: + +dev_weight FIXME +discovery_slots FIXME +discovery_timeout FIXME +fast_poll_increase FIXME +ip6_queue_maxlen FIXME +lap_keepalive_time FIXME +lo_cong FIXME +max_baud_rate FIXME +max_dgram_qlen FIXME +max_noreply_time FIXME +max_tx_data_size FIXME +max_tx_window FIXME +min_tx_turn_time FIXME +mod_cong FIXME +no_cong FIXME +no_cong_thresh FIXME +slot_timeout FIXME +warn_noreply_time FIXME $Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $ From vda@port.imtp.ilyichevsk.odessa.ua Tue Jun 15 23:57:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Jun 2004 23:57: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.12.10/8.12.9) with SMTP id i5G6jOgi032287 for ; Tue, 15 Jun 2004 23:46:40 -0700 Received: (qmail 12707 invoked by alias); 16 Jun 2004 06:37:55 -0000 Received: from vda@port.imtp.ilyichevsk.odessa.ua by guard by uid 80 with qmail-scanner-1.22 ( Clear:RC:1(172.16.42.177):. Processed in 0.362291 secs); 16 Jun 2004 06:37:55 -0000 Received: from unknown (HELO firebird) (172.16.42.177) by 0 (172.16.22.3) with ESMTP; 16 Jun 2004 06:37:51 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Denis Vlasenko To: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez), Margit Schubert-While Subject: Re: [Prism54-devel] GUPD (Grand Unified Prism54 Driver) Open discussion Date: Wed, 16 Jun 2004 09:37:50 +0300 X-Mailer: KMail [version 1.4] Cc: Netdev , prism54-devel@prism54.org References: <5.1.0.14.2.20040615143603.02a40b48@pop.t-online.de> <20040616001111.GK6253@ruslug.rutgers.edu> In-Reply-To: <20040616001111.GK6253@ruslug.rutgers.edu> MIME-Version: 1.0 Message-Id: <200406160937.50943.vda@port.imtp.ilyichevsk.odessa.ua> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5G6jOgi032287 X-archive-position: 5970 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: 1233 Lines: 38 > * WDS - Umm someone on the list had mentioned they had used WDS > successfully and had some patches (?) Are you still alive? Are you > still working on this? No promises, but I'd like to take a look at WDS, since I just got another prism54. There is one problem - I don't know what WDS is supposed to do, because I use WDS link with hostap driver in a awkward way - I *turn off* AP bridging. This turns AP into kind of multihomed pseudo ethernet device which does NOT automatically forward packets from one STA to another (it is done via normal IP routing instead). In this setup, logically WDSes are just another devices, distinct from AP: +--------------+ +AP-+ | core kernel |<-------| < | <--------- STA1 |(does routing)|------->| > | ---------> STA2 | | +---+ | | +WDS+ | |<------>|<->| <--------> WDS peer +--------------+ +---+ I suspect that most other people do not disable bridging. For them WDS cannot be a separate device... or what? I'm lost here. Let's imagine three APs linked with WDS (double links in a picture below): sta1 <---> AP1 <===> AP2 <===> AP3 <---> sta2 Say, sta1 wants to sent a packet to sta2. What should happen? -- vda From mcgrof@studorgs.rutgers.edu Wed Jun 16 00:14:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 00:14:24 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G7E0gi000988 for ; Wed, 16 Jun 2004 00:14:00 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id CA654F9D4D; Wed, 16 Jun 2004 02:43:03 -0400 (EDT) Date: Wed, 16 Jun 2004 02:43:03 -0400 To: Jeff Garzik , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54] CVS -> bk tree update Message-ID: <20040616064303.GO6253@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , Netdev , prism54-devel@prism54.org References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> <20040616022008.GM6253@ruslug.rutgers.edu> <40CFBA24.7030307@pobox.com> <20040616051103.GN6253@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NQTVMVnDVuULnIzU" Content-Disposition: inline In-Reply-To: <20040616051103.GN6253@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: 5971 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: 621 Lines: 30 --NQTVMVnDVuULnIzU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff, Ok 2.6.7 is out, we missed it. Now what, send a group of patches against th= at then? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --NQTVMVnDVuULnIzU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAz+v3at1JN+IKUl4RAsyVAJ4ooQ7rvFRLiB10E/Hd2D3aAIU+HQCfbpVa 8jqz4K8z09gkbKc7SrRrajs= =ukdE -----END PGP SIGNATURE----- --NQTVMVnDVuULnIzU-- From dada1@cosmosbay.com Wed Jun 16 01:37:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 01:37:55 -0700 (PDT) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G8bggi010172 for ; Wed, 16 Jun 2004 01:37:43 -0700 Received: from cosmosbay.com (edumazet-port [172.16.0.131]) (authenticated bits=0) by gw1.cosmosbay.com (8.12.9/8.12.9) with ESMTP id i5G8bIju007459; Wed, 16 Jun 2004 10:37:25 +0200 Message-ID: <40D006BF.7020002@cosmosbay.com> Date: Wed, 16 Jun 2004 10:37:19 +0200 From: Eric Dumazet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: bert hubert , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [DOCUMENTATION PATCH] Missing net sysctls, some fixed, rest flagged References: <20040609175242.GA13875@outpost.ds9a.nl> <20040615201912.691ffe35.davem@redhat.com> In-Reply-To: <20040615201912.691ffe35.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5972 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: 467 Lines: 24 David S. Miller wrote: >+somaxconn - INTEGER >+ Limit of TCP listen backlog, known in userspace as SOMAXCONN. >+ Defaults to 128 >+ > > Hmm... I dont agree with the 'TCP' word here : listen() system call is not tied with TCP, isn't it ? I would suggest : +somaxconn - INTEGER + Limit of socket listen() backlog, known in userspace as SOMAXCONN. + Defaults to 128. See also tcp_max_syn_backlog for additional tuning for TCP sockets. + Thank you Eric Dumazet From sfeldma@pobox.com Wed Jun 16 02:26:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 02:26:36 -0700 (PDT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G9QWgi011543 for ; Wed, 16 Jun 2004 02:26:32 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out011.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040616091325.CXVA18566.out011.verizon.net@[192.168.0.79]>; Wed, 16 Jun 2004 04:13:25 -0500 Subject: Re: [RFC] Wireless extensions rethink From: Scott Feldman Reply-To: sfeldma@pobox.com To: Gertjan van Wingerde Cc: netdev@oss.sgi.com In-Reply-To: <40CF263E.70009@home.nl> References: <40CF263E.70009@home.nl> Content-Type: text/plain Message-Id: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 02:13:18 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [4.5.57.153] at Wed, 16 Jun 2004 04:13:25 -0500 X-archive-position: 5973 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: 6819 Lines: 186 On Tue, 2004-06-15 at 09:39, Gertjan van Wingerde wrote: > Sounds like a good idea. I'll start refactoring my work towards that approach. Please bear > with me for a couple of days and I'll post a draft patch for this. Gertjan, 24 clock: see how this patch looks. It adds just two more ETHTOOL_[G|S]WSET commands to handle the get/set of the wireless settings. This works just like ETHTOOL_[G|S]SET by passing in/out a struct ethtool_wx_cmd that holds all of the wireless settings. The idea is the application would get the settings from the driver, let the user change one or more of the settings, and send all of the settings back to the driver. The driver just resets all settings in one shot. I tried to use the correct type for the various settings based on what the drivers did (unwinding the iw_param and iw_point members). I probably missed some details; please help. Some observations/opens: 1) This is not compatible with the current wireless extensions ioctl, so iwconfig must be re-written to use ethtool -w. :( 2) Note that wireless stats can just be moved into ETHTOOL_GSTATS. 3) iw_range needs another ETHTOOL_GWRANGE, but it looks like there is some duplication with ETHTOOL_GWSET, so I'm not sure what's left - would you look into this? 4) nick is cosmetic, so it's not included here. 5) Individual events are not generated for things like setting ESSID and NWID. Since all of these settings are now set in batch, there really is just one event: wireless settings changed. Event needs to come from the ethtool_ops->get_wx_settings() so it's generated regardless of UI. On the other hand, is there any practical use for the event in the first place? We don't have events for LAN drivers when speed/duplex change, for example, do we? 6) The whole commit strategy is useless to us now because settings are always set in batch with ETHTOOL_GWSET. The driver does an implicit commit after applying settings. 7) We need a driver to prototype this against - I'm using ipw2100, but it would be better to use something that's already in the kernel. 8) We need ethtool app updates to add a -w option to set wireless settings. 9) ethtool DEVNAME would use either get_settings or get_wx_settings, depending on which one was implemented in the driver. 10) Not sure what to do with get/set scan. See if you can make some progress on these open issues. -scott ---------------- diff -Naurp linux-2.6.7-rc3-bk1/include/linux/ethtool.h linux-2.6.7-rc3-bk1-ethtool/include/linux/ethtool.h --- linux-2.6.7-rc3-bk1/include/linux/ethtool.h 2004-05-09 19:32:26.000000000 -0700 +++ linux-2.6.7-rc3-bk1-ethtool/include/linux/ethtool.h 2004-06-16 01:09:44.018094360 -0700 @@ -250,6 +250,49 @@ struct ethtool_stats { u64 data[0]; }; +enum ethtool_wx_mode { + ETH_WX_MODE_AUTO = 0, + ETH_WX_MODE_ADHOC, + ETH_WX_MODE_INFRA, + ETH_WX_MODE_MASTER, + ETH_WX_MODE_REPEATER, + ETH_WX_MODE_SECOND, + ETH_WX_MODE_MONITOR, +}; + +enum ethtool_wx_sec_mode { + ETH_WX_SEC_MODE_OPEN = 0, + ETH_WX_SEC_MODE_RESTRICTED, +}; + +/* for getting/setting wireless settings */ +struct ethtool_wx_cmd { + u32 cmd; + u16 nwid; /* Wireless network ID; 0 = disabled */ + struct { + u32 mantissa; + u16 exponent; + } freq; /* Operating frequency */ + u32 mode; /* Operating mode (ETH_WX_MODE_xxx) */ + u16 sens; /* Sensitivity threshold (-dBm) */ + struct sockaddr wap; /* Register with access point */ + /* auto = 00:00:00:00:00:00 */ + char essid[32]; /* ESSID; any = NULL string */ + u32 rate; /* Bit rate b/s; 0 = auto */ + u16 rts; /* Smallest packet size for which */ + /* the node sends RTS; 0 = off */ + u16 frag; /* Maximum fragment size; 0 = no frag */ + u16 tx_power; /* Transmit power in dBm */ + struct { /* TODO: thit needs work */ + u16 limit; + u32 lifetime; /* usec */ + } retry; /* MAC retransmission */ + u32 sec_mode; /* Security mode (ETH_WX_SEC_MODE_xxx) */ + char sec_key[32]; /* Security mode encryption key */ + /* TODO: add struct power */ + u32 reserved[16]; +}; + struct net_device; /* Some generic methods drivers may use in their ethtool_ops */ @@ -293,6 +336,8 @@ int ethtool_op_set_tso(struct net_device * get_strings: Return a set of strings that describe the requested objects * phys_id: Identify the device * get_stats: Return statistics about the device + * get_wx_settings: Get device-specific wireless settings + * set_wx_settings: Set device-specific wireless settings * * Description: * @@ -351,6 +396,8 @@ struct ethtool_ops { int (*phys_id)(struct net_device *, u32); int (*get_stats_count)(struct net_device *); void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *); + int (*get_wx_settings)(struct net_device *, struct ethtool_wx_cmd *); + int (*set_wx_settings)(struct net_device *, struct ethtool_wx_cmd *); }; /* CMDs currently supported */ @@ -386,6 +433,8 @@ struct ethtool_ops { #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ +#define ETHTOOL_GWSET 0x00000020 /* Get wireless settings. */ +#define ETHTOOL_SWSET 0x00000021 /* Set wireless settings. */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET diff -Naurp linux-2.6.7-rc3-bk1/net/core/ethtool.c linux-2.6.7-rc3-bk1-ethtool/net/core/ethtool.c --- linux-2.6.7-rc3-bk1/net/core/ethtool.c 2004-06-08 11:13:53.000000000 -0700 +++ linux-2.6.7-rc3-bk1-ethtool/net/core/ethtool.c 2004-06-16 01:13:52.615301840 -0700 @@ -645,6 +645,36 @@ static int ethtool_get_stats(struct net_ return ret; } +static int ethtool_get_wx_settings(struct net_device *dev, void __user *useraddr) +{ + struct ethtool_wx_cmd cmd = { ETHTOOL_GWSET }; + int err; + + if (!dev->ethtool_ops->get_wx_settings) + return -EOPNOTSUPP; + + err = dev->ethtool_ops->get_wx_settings(dev, &cmd); + if (err < 0) + return err; + + if (copy_to_user(useraddr, &cmd, sizeof(cmd))) + return -EFAULT; + return 0; +} + +static int ethtool_set_wx_settings(struct net_device *dev, void __user *useraddr) +{ + struct ethtool_wx_cmd cmd; + + if (!dev->ethtool_ops->set_wx_settings) + return -EOPNOTSUPP; + + if (copy_from_user(&cmd, useraddr, sizeof(cmd))) + return -EFAULT; + + return dev->ethtool_ops->set_wx_settings(dev, &cmd); +} + /* The main entry point in this file. Called from net/core/dev.c */ int dev_ethtool(struct ifreq *ifr) @@ -730,6 +760,10 @@ int dev_ethtool(struct ifreq *ifr) return ethtool_phys_id(dev, useraddr); case ETHTOOL_GSTATS: return ethtool_get_stats(dev, useraddr); + case ETHTOOL_GWSET: + return ethtool_get_wx_settings(dev, useraddr); + case ETHTOOL_SWSET: + return ethtool_set_wx_settings(dev, useraddr); default: return -EOPNOTSUPP; } From jgarzik@pobox.com Wed Jun 16 03:19:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 03:19: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.12.10/8.12.9) with SMTP id i5GAJ5gi015168 for ; Wed, 16 Jun 2004 03:19:06 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BaQp0-0000hs-0S; Wed, 16 Jun 2004 04:10:42 +0100 Message-ID: <40CFBA24.7030307@pobox.com> Date: Tue, 15 Jun 2004 23:10:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54] CVS -> bk tree update References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> <20040616022008.GM6253@ruslug.rutgers.edu> In-Reply-To: <20040616022008.GM6253@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5974 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: 1184 Lines: 29 Luis R. Rodriguez wrote: > Thanks Jeff. I did, and a diff of Andrew's -mm tree Vs our cvs tree > 2.6.7-prism54 gives a 1898 line diff. This is excluding spaces, > newlines, and tabbing and all of Andew's .orig, .rej's. > > This time it's going to be a *real* pain to provide a changelog and split the > diffs.. so can I just send you that 1898 line diff and then another for > space changes? Everything has already been reviewed on the lists here... > > I promise this will be our last big patch too. I'll ask our team > to send patches from now on to netdev after each ChangeLog entry, for > more public review and to not loose sync of our trees. Let us know if > you think we should do otherwise. Sorry, no. You knew that split-up patches would be needed, once the initial driver merge is complete (which was complete before the most recent series of 17 patches). This is one of the big downsides to developing in CVS, and it bites people again and again. Linux kernel development relies on split-up patches for review, testing, and narrowing down which patch in a series introduced a bug. There are real, engineering-related reasons we do things this way. Jeff From kala@pinerecords.com Wed Jun 16 04:13:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 04:15:13 -0700 (PDT) Received: from louise.pinerecords.com (louise.pinerecords.com [213.168.176.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GBDagi017005 for ; Wed, 16 Jun 2004 04:13:37 -0700 Received: from louise.pinerecords.com (localhost [127.0.0.1]) by louise.pinerecords.com with ESMTP id i5GBDTX5001621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2004 13:13:29 +0200 Received: (from kala@localhost) by louise.pinerecords.com (submit) id i5GBDTDE001620; Wed, 16 Jun 2004 13:13:29 +0200 Date: Wed, 16 Jun 2004 13:13:29 +0200 From: Tomas Szepe To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: Linux 2.6.7 Message-ID: <20040616111329.GA1571@louise.pinerecords.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 5975 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szepe@pinerecords.com Precedence: bulk X-list: netdev Content-Length: 371 Lines: 14 On Jun-15 2004, Tue, 22:56 -0700 Linus Torvalds wrote: > Summary of changes from v2.6.7-rc3 to v2.6.7 [snip] 2.6.7's airo.ko (unlike 2.6.6's) won't allow the user to set ESSID via "echo myessid >/proc/driver/aironet/ethX/SSID". Changes like this shouldn't probably be made in the middle of a stable series. -- Tomas Szepe From herbert@gondor.apana.org.au Wed Jun 16 04:22:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 04:22:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GBMOgi020527 for ; Wed, 16 Jun 2004 04:22: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 1BaYUi-0003zO-00; Wed, 16 Jun 2004 21:22:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BaYUe-0000Gf-00; Wed, 16 Jun 2004 21:22:12 +1000 Date: Wed, 16 Jun 2004 21:22:11 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NET] Clear dev refs in dst->child Message-ID: <20040616112211.GA956@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5976 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: 3455 Lines: 117 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is a resend of an earlier patch to dst_dev_event. I've changed it slightly by moving the input/output assignment into dst_ifdown. To recap, this patch drops lingering IPsec references to a device that is being unregistered. The child processing in the GC is too late since it never runs until the reference on the dst hits zero which could take a long time for things like TCP connections. The reason I've left the input/output assignment outside the loop is because they aren't really necessary for the IPsec dst's, and if it were in the loop then we'll have to do the same child processing in ___dst_free as well. I've tested this with an ESP/IPCOMP tunnel and I can confirm that it does fix the problem. 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 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/core/dst.c 1.17 vs edited ===== --- 1.17/net/core/dst.c 2004-06-13 03:51:53 +10:00 +++ edited/net/core/dst.c 2004-06-16 21:14:18 +10:00 @@ -210,6 +210,41 @@ return NULL; } +/* Dirty hack. We did it in 2.2 (in __dst_free), + * we have _very_ good reasons not to repeat + * this mistake in 2.3, but we have no choice + * now. _It_ _is_ _explicit_ _deliberate_ + * _race_ _condition_. + * + * Commented and originally written by Alexey. + */ +static void dst_ifdown(struct dst_entry *dst, int unregister) +{ + struct net_device *dev = dst->dev; + + if (!unregister) { + dst->input = dst_discard_in; + dst->output = dst_discard_out; + } + + do { + if (unregister) { + dst->dev = &loopback_dev; + dev_hold(&loopback_dev); + dev_put(dev); + if (dst->neighbour && dst->neighbour->dev == dev) { + dst->neighbour->dev = &loopback_dev; + dev_put(dev); + dev_hold(&loopback_dev); + } + } + + if (dst->ops->ifdown) + dst->ops->ifdown(dst, unregister); + } while ((dst = dst->child) && dst->flags & DST_NOHASH && + dst->dev == dev); +} + static int dst_dev_event(struct notifier_block *this, unsigned long event, void *ptr) { struct net_device *dev = ptr; @@ -220,31 +255,8 @@ case NETDEV_DOWN: spin_lock_bh(&dst_lock); for (dst = dst_garbage_list; dst; dst = dst->next) { - if (dst->dev == dev) { - /* Dirty hack. We did it in 2.2 (in __dst_free), - we have _very_ good reasons not to repeat - this mistake in 2.3, but we have no choice - now. _It_ _is_ _explicit_ _deliberate_ - _race_ _condition_. - */ - if (event!=NETDEV_DOWN && - dst->output == dst_discard_out) { - dst->dev = &loopback_dev; - dev_hold(&loopback_dev); - dev_put(dev); - dst->output = dst_discard_out; - if (dst->neighbour && dst->neighbour->dev == dev) { - dst->neighbour->dev = &loopback_dev; - dev_put(dev); - dev_hold(&loopback_dev); - } - } else { - dst->input = dst_discard_in; - dst->output = dst_discard_out; - } - if (dst->ops->ifdown) - dst->ops->ifdown(dst, event != NETDEV_DOWN); - } + if (dst->dev == dev) + dst_ifdown(dst, event != NETDEV_DOWN); } spin_unlock_bh(&dst_lock); break; --CE+1k2dSO48ffgeK-- From david@dgreaves.com Wed Jun 16 04:33:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 04:33:36 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GBXMgi021211 for ; Wed, 16 Jun 2004 04:33:23 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 954DFE6DC6; Wed, 16 Jun 2004 11:59:14 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04947-10; Wed, 16 Jun 2004 11:59:14 +0100 (BST) Received: from oak.dgreaves.com (modem-2768.putangitangi.dialup.pol.co.uk [81.78.202.208]) by mail.ukfsn.org (Postfix) with ESMTP id 20527E6DC4; Wed, 16 Jun 2004 11:59:13 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.126]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BaYAS-00016A-ST; Wed, 16 Jun 2004 12:01:20 +0100 Message-ID: <40D0280B.2030308@dgreaves.com> Date: Wed, 16 Jun 2004 11:59:23 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> In-Reply-To: <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 3235 Lines: 84 Stephen Hemminger wrote: >How big is the transmit ring. Setting a bigger transmit ring fixed my problem > modprobe e1000 TxDescriptors=1024 > >Also, there are lots of flavors of this chipset and board. One machine >I was using had the IBM rebranded version and it would only do PCI33 not PCI66. > > > Thanks for replying Stephen - it's really frustrating :) I did try TxDescriptors and various (most) other parameters (below are the actual parameter variations I tried - just cut from a 'history' for info). After each one i downed the link and modprobe -r the driver. I then ran a large file scp (quicker id+recovery than nfs hanging when the link died) I invariably got an eth0 timed out after a few seconds - some variation but IIRC no more than 20% - ie 8-10Mb of a 1G file before it failed. root@ash:~ # ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 1024 I've pulled all the cards and looked - they are all genuine Intel C39226-003 (Pro/1000 MT) This page http://support.intel.com/support/network/sb/cs-005980-prd38.htm says: 82541 Gigabit Small Form 32/66 My system has PCI33 BTW. I have also tried 2.6.7 this morning and have the same problem. David module parameters. modprobe e1000 FlowControl=2 modprobe e1000 FlowControl=1 modprobe e1000 FlowControl=3 modprobe e1000 FlowControl=0 modprobe e1000 FlowControl=0 InterruptThrottleRate=100 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=1024 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=4096 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=1 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=10 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=1000 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=0 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=0 TxIntDelay=0 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=1024 TxIntDelay=53 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=1024 TxIntDelay=64 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=65535 TxIntDelay=64 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=128 TxIntDelay=0 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=128 TxIntDelay=32000 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=128 TxIntDelay=32000 ; ifup eth0 modprobe e1000 FlowControl=0 InterruptThrottleRate=1 RxDescriptors=256 RxIntDelay=0 RxAbsIntDelay=128 TxIntDelay=64 XsumRX=1 ; ifup eth0 modprobe e1000 Speed=100 modprobe e1000 Speed=10 From herbert@gondor.apana.org.au Wed Jun 16 04:45:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 04:45:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GBj1gi021930 for ; Wed, 16 Jun 2004 04:45: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 1BaYpg-000498-00; Wed, 16 Jun 2004 21:43:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BaYpV-0000PO-00; Wed, 16 Jun 2004 21:43:45 +1000 Date: Wed, 16 Jun 2004 21:43:45 +1000 To: Michael Richardson Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040616114345.GA1559@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <32703.1087311037@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32703.1087311037@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5978 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: 640 Lines: 13 On Tue, Jun 15, 2004 at 10:50:37AM -0400, Michael Richardson wrote: > > The pmtu WG is considering changing how PMTU is done. You may want to > look at draft-richardson-ipsec-fragment-XX.txt. This has not yet been > adopted as a WG draft, because nobody is sure which WG should adopt it:-) I'd say that we should get the stack to work with the hosts that do send ICMP replies first, and then worry about those that don't :) -- 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 Wed Jun 16 05:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 05:06:04 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GC5xgi022801 for ; Wed, 16 Jun 2004 05:06:00 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id DDA88366; Wed, 16 Jun 2004 14:05:54 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id B6D48302D4; Wed, 16 Jun 2004 13:13:44 +0200 (CEST) To: "Eble, Dan" Cc: "'netdev@oss.sgi.com'" Subject: Re: RFC: Cisco HDLC bridging References: From: Krzysztof Halasa Date: Wed, 16 Jun 2004 13:13:44 +0200 In-Reply-To: (Dan Eble's message of "Mon, 14 Jun 2004 09:40:23 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5979 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 Content-Length: 2569 Lines: 66 "Eble, Dan" writes: > Krzysztof, I thought you had dropped off the face of the earth. Good to > hear from you again. Did you ever see my changes to make the HDLC generic > layer use the PPP generic layer instead of syncppp.c? Not sure. Do you have a copy? > I thought tcpdump/libpcap only looked at the device type, so that if we sent > non-eth packets up an eth interface, tcpdump would try to interpret them as > eth packets. Sure. But we won't - with device type = Cisco HDLC tcpdump will be happy. I.e. will happily print SLARPs, regular IP frames, and Ethernet frames. Looks like it doesn't support it yet: switch (proto) { case ETHERTYPE_IP: case ETHERTYPE_IPV6: case CHDLC_TYPE_SLARP: case CHDLC_TYPE_CDP: case ETHERTYPE_MPLS: case ETHERTYPE_MPLS_MULTI: case ETHERTYPE_ISO: but I can't see a problem with adding it, given the kernel code is confirmed working so I can test it. Note it's irrelevant to single hdlcX vs hdlcX + hdlcXeth0 issue, it has to be done anyway. > My primary reason for wanting a second device is to be sure > not to discard information that is helpful/necessary for troubleshooting; > so, if receiving packets with diverse header types is not going to mess > things up, I would definitely prefer using only one device, because it is > simpler to configure. Receive side is definitely not a problem. Transmit side is and I think we need two devices, at least for now. > The case of using a Cisco HDLC link for bridged > ethernet *and* IP *and* other things at the same time does not seem very > useful. But it's more elegant solution I think (the same would apply to FR PVCs). It could be useful - with bridged Ethernet for MS Windows connectivity and with routed IP traffic. >> The only problem I can see (a serious one, though) is the protocol >> "routing" in Linux. If we "ip addr add" IP address to hdlcX, does >> it mean we want native IP or IP/Ethernet? It would be nice to be able >> to: >> ifconfig hdlc0 10.0.0.1/24 hw cisco-hdlc >> ifconfig hdlc0 10.0.1.1/24 hw ether > > We could just use "sethdlc hdlc0 cisco-eth" and not worry about > distinguishing in ifconfig, right? Sure, but that wouldn't be "at a time". I'd go with "2 devices" path for now. Long-term I'm going to investigate "1 device" possibility. This depends on my future job = time I can find for it, as my current contract ends by Sep, 1 and I'll be seeking a new one (hope I'll have more time for Linux works than now). -- Krzysztof Halasa, B*FH From khc@pm.waw.pl Wed Jun 16 05:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 05:06:04 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GC5xgi022804 for ; Wed, 16 Jun 2004 05:06:00 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 1A777358; Wed, 16 Jun 2004 14:05:55 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 039B1302D4; Wed, 16 Jun 2004 13:55:32 +0200 (CEST) To: "Eble, Dan" Cc: "'netdev@oss.sgi.com'" Subject: Re: serial port-to-netdevice tap References: From: Krzysztof Halasa Date: Wed, 16 Jun 2004 13:55:32 +0200 In-Reply-To: (Dan Eble's message of "Tue, 15 Jun 2004 11:50:01 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5980 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 Content-Length: 823 Lines: 18 "Eble, Dan" writes: > A coworker of mine wants an easy way to monitor data transfer and control > line changes on an serial port. His first impulse was to create a /proc > file, but I suggested a netlink socket, or even a raw net device so that he > can take advantage of libpcap for some pretty powerful filtering. Does > anything like this exist already? With character device? I don't think so. One could use a pseudo terminal combo, though. Another option is to use two additional ports with their RX lines connected to both TX and RX lines of the main port. Depends on requirements. I use a "data acquisition" card with all the async serial protocol etc. analysis in (quite simple) software. A "strace" (if you want to see what a process does) could be a help as well. -- Krzysztof Halasa, B*FH From herbert@gondor.apana.org.au Wed Jun 16 05:11:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 05:11:27 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GCBIgi023612 for ; Wed, 16 Jun 2004 05:11:19 -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 1BaZFO-0004J5-00; Wed, 16 Jun 2004 22:10:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BaZFK-0000Rx-00; Wed, 16 Jun 2004 22:10:26 +1000 Date: Wed, 16 Jun 2004 22:10:26 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040616121026.GA1169@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615124334.GA25164@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 5981 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: 2741 Lines: 70 On Tue, Jun 15, 2004 at 10:43:34PM +1000, herbert wrote: > > So unless I'm missing something, we should get rid of dst->path and > store the MTU in the xfrm dst's directly. Actually that's still broken for nested tunnels. If we get an ICMP packet for a peer in the middle of the bundle, it is not easy to find the corresponding dst's to update. So how about this solution: MTU Barriers ------------ We divide each bundle into segments with the property that within each segment the local/remote addresses do not change. For example, the following nested template will be divided into two segments: ipcomp/tunnel/192.168.0.2-192.168.0.1/ esp/transport// <-------------Check MTU--------------> esp/tunnel/10.0.0.2-10.0.0.1/ Between each pair of segments we will add an MTU-checking dst whose path is set to the route entry of the corresponding local/remote address. For example, in the above scenario we'll add such a dst after the esp/transport// SA and set its path to the route entry for 192.168.0.2 to 192.168.0.1. We will also store the computed MTU for each dst in itself at creation time. This is modified subsequently through update_pmtu. As an example, let's say that we receive an ICMP packet where the original header is from 192.168.0.2 to 192.168.0.1. We will update the MTU in the corresponding route entry, which will then cause the dst_pmtu of the MTU-checking dst to be reduced. If a subsequent large packet is transmitted through the bundle, it should fail at the MTU-checking dst and send back an ICMP error. The error should then filter through the bundle by update_pmtu. This takes care of ICMP packets for IPsec peers in the middle of a bundle. Flow Cache ---------- We will also modify the flow cache to store bundles instead of outgoing policies (Incoming/forward policies will stay as is). The reason is that within each bundle, the MTU may still differ depending on the final destination address. Thus we will add another MTU-checking dst at the front of each bundle. Its path will be set to the route entry that triggered the lookup. This dst will then be stored inside the flow cache. This takes care of ICMP packets for destination hosts over IPsec. Conclusion ---------- Now the problem with all this is that it looks pretty complicated. So I'd like to hear from you that this is all unnecessary and that one of you already has a solution for it all :) Seriously, I'd appreciate comments on this proposal or other proposals about the interaction between PMTU and IPsec. 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 viro@www.linux.org.uk Wed Jun 16 05:18:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 05:18:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GCIpgi024159 for ; Wed, 16 Jun 2004 05:18:52 -0700 Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1BaZNT-0000Du-2k; Wed, 16 Jun 2004 13:18:51 +0100 Date: Wed, 16 Jun 2004 13:18:51 +0100 From: viro@parcelfarce.linux.theplanet.co.uk To: Tomas Szepe Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Linux 2.6.7 Message-ID: <20040616121850.GO12308@parcelfarce.linux.theplanet.co.uk> References: <20040616111329.GA1571@louise.pinerecords.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616111329.GA1571@louise.pinerecords.com> User-Agent: Mutt/1.4.1i X-archive-position: 5982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: viro@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: netdev Content-Length: 1033 Lines: 30 On Wed, Jun 16, 2004 at 01:13:29PM +0200, Tomas Szepe wrote: > On Jun-15 2004, Tue, 22:56 -0700 > Linus Torvalds wrote: > > > Summary of changes from v2.6.7-rc3 to v2.6.7 > [snip] > > 2.6.7's airo.ko (unlike 2.6.6's) won't allow the user to set > ESSID via "echo myessid >/proc/driver/aironet/ethX/SSID". > > Changes like this shouldn't probably be made in the middle > of a stable series. Changes like this are called bugs. The thing is, original variant of function (actually, both read and write) was also buggy and trivially exploitable, so fixing it was needed. Fscking it up was not, obviously. Fix follows; see if it works for you. --- RC7/drivers/net/wireless/airo.c Mon Jun 7 19:21:27 2004 +++ RC7-current/drivers/net/wireless/airo.c Wed Jun 16 08:11:50 2004 @@ -4527,6 +4527,8 @@ len = priv->maxwritelen - pos; if (copy_from_user(priv->wbuffer + pos, buffer, len)) return -EFAULT; + if (pos + len > priv->writelen) + priv->writelen = pos + len; *offset = pos + len; return len; } From DanE@aiinet.com Wed Jun 16 05:58:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 05:59:28 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GCwkgi025287 for ; Wed, 16 Jun 2004 05:58:46 -0700 Received: by AIMAIL1.ai.aiinet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jun 2004 08:58:35 -0400 Message-ID: From: "Eble, Dan" To: "'Krzysztof Halasa'" Cc: "'netdev@oss.sgi.com'" Subject: RE: RFC: Cisco HDLC bridging Date: Wed, 16 Jun 2004 08:58:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 5983 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 Content-Length: 1385 Lines: 38 > -----Original Message----- > From: Krzysztof Halasa [mailto:khc@pm.waw.pl] > Sent: Wednesday, June 16, 2004 7:14 AM ... > Sure. But we won't - with device type = Cisco HDLC tcpdump > will be happy. > I.e. will happily print SLARPs, regular IP frames, and > Ethernet frames. Ah, yes. But if the device does not have ARPHRD_ETHER the bridge driver will not allow it to be used as a port. I do not know what else may require ARPHRD_ETHER, but I'm not keen to find out by trial and error (and then fix everything to work with ARPHRD_CISCO too). > It could be useful - with bridged Ethernet for MS Windows connectivity > and with routed IP traffic. When all you have is a hammer, MS Windows looks like a nail. :-) > I'd go with "2 devices" path for now. It is going well so far. I will post patches when I am done, but they probably will not apply to the current public versions without some extra work. This is the sethdlc syntax I have chosen to create and destroy the hdlcXeth0 device: sethdlc hdlc0 cisco proto [ enable | disable ] Where is 0x6558 for bridged ethernet packets (or maybe "ether", but I have not put that in yet). I figure this will be useful to enable and disable other protocols too. -- Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| From rl@hellgate.ch Wed Jun 16 06:16:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 06:17:30 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GDGwgi026111 for ; Wed, 16 Jun 2004 06:16:58 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40BC705C001FCA00; Tue, 15 Jun 2004 17:49:11 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 33C2921F343; Tue, 15 Jun 2004 19:49:10 +0200 (CEST) Date: Tue, 15 Jun 2004 19:49:10 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [4/9][PATCH 2.6] Rewrite PHY detection Message-ID: <20040615174910.GA11215@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 6004 Lines: 192 Instead of probing, set phy_id to 1 for Rhine III and read phy_id from EEPROM-controlled register for Rhine I/II. Remove code for handling anything other than 1 MII PHY. If it wasn't unnecessary code to begin with, it would need to be fixed because it wouldn't work. Use mii_if_info.phy_id as the only container of phy_id. Not particulary happy about those names (phy_id vs. MII_PHYSIDx), but being consequent about it mitigates confusion. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -475,7 +475,6 @@ CmdNoTxPoll=0x0800, CmdReset=0x8000, }; -#define MAX_MII_CNT 4 struct rhine_private { /* Descriptor rings */ struct rx_desc *rx_ring; @@ -513,8 +512,6 @@ u8 tx_thresh, rx_thresh; /* MII transceiver section. */ - unsigned char phys[MAX_MII_CNT]; /* MII device addresses. */ - unsigned int mii_cnt; /* number of MIIs found, but only the first one is used */ u16 mii_status; /* last read MII status */ struct mii_if_info mii_if; }; @@ -622,6 +619,7 @@ /* * Loads bytes 0x00-0x05, 0x6E-0x6F, 0x78-0x7B from EEPROM + * (plus 0x6C for Rhine I/II) */ static void __devinit rhine_reload_eeprom(long pioaddr, struct net_device *dev) { @@ -680,8 +678,7 @@ long pioaddr; long memaddr; long ioaddr; - int io_size; - int phy, phy_idx = 0; + int io_size, phy_id; const char *name; /* when built into the kernel, we only print version if device is found */ @@ -696,6 +693,7 @@ pci_read_config_byte(pdev, PCI_REVISION_ID, &pci_rev); io_size = 256; + phy_id = 0; if (pci_rev < VT6102) { quirks = rqRhineI; io_size = 128; @@ -709,6 +707,7 @@ } else { name = "Rhine III"; + phy_id = 1; /* Integrated PHY, phy_id fixed to 1 */ if (pci_rev >= VT6105_B0) quirks |= rq6patterns; } @@ -804,6 +803,10 @@ writeb(readb(ioaddr + ConfigD) & (0xF0 | backoff), ioaddr + ConfigD); + /* For Rhine I/II, phy_id is loaded from EEPROM */ + if (!phy_id) + phy_id = readb(ioaddr + 0x6C); + dev->irq = pdev->irq; spin_lock_init(&rp->lock); @@ -867,17 +870,15 @@ pci_set_drvdata(pdev, dev); - rp->phys[0] = 1; /* Standard for this chip. */ - for (phy = 1; phy < 32 && phy_idx < MAX_MII_CNT; phy++) { - int mii_status = mdio_read(dev, phy, 1); + { + int mii_status = mdio_read(dev, phy_id, 1); if (mii_status != 0xffff && mii_status != 0x0000) { - rp->phys[phy_idx++] = phy; - rp->mii_if.advertising = mdio_read(dev, phy, 4); + rp->mii_if.advertising = mdio_read(dev, phy_id, 4); printk(KERN_INFO "%s: MII PHY found at address " "%d, status 0x%4.4x advertising %4.4x " - "Link %4.4x.\n", dev->name, phy, + "Link %4.4x.\n", dev->name, phy_id, mii_status, rp->mii_if.advertising, - mdio_read(dev, phy, 5)); + mdio_read(dev, phy_id, 5)); /* set IFF_RUNNING */ if (mii_status & BMSR_LSTATUS) @@ -885,11 +886,9 @@ else netif_carrier_off(dev); - break; } } - rp->mii_cnt = phy_idx; - rp->mii_if.phy_id = rp->phys[0]; + rp->mii_if.phy_id = phy_id; /* Allow forcing the media type. */ if (option > 0) { @@ -900,10 +899,9 @@ "operation.\n", (option & 0x300 ? 100 : 10), (option & 0x220 ? "full" : "half")); - if (rp->mii_cnt) - mdio_write(dev, rp->phys[0], MII_BMCR, - ((option & 0x300) ? 0x2000 : 0) | /* 100mbps? */ - ((option & 0x220) ? 0x0100 : 0)); /* Full duplex? */ + mdio_write(dev, phy_id, MII_BMCR, + ((option & 0x300) ? 0x2000 : 0) | /* 100mbps? */ + ((option & 0x220) ? 0x0100 : 0)); /* Full duplex? */ } } @@ -1140,7 +1138,7 @@ long ioaddr = dev->base_addr; int boguscnt = 1024; - if (phy_id == rp->phys[0]) { + if (phy_id == rp->mii_if.phy_id) { switch (regnum) { case MII_BMCR: /* Is user forcing speed/duplex? */ if (value & 0x9000) /* Autonegotiation. */ @@ -1191,7 +1189,7 @@ printk(KERN_DEBUG "%s: Done rhine_open(), status %4.4x " "MII status: %4.4x.\n", dev->name, readw(ioaddr + ChipCmd), - mdio_read(dev, rp->phys[0], MII_BMSR)); + mdio_read(dev, rp->mii_if.phy_id, MII_BMSR)); netif_start_queue(dev); @@ -1209,7 +1207,7 @@ { struct rhine_private *rp = netdev_priv(dev); long ioaddr = dev->base_addr; - int mii_lpa = mdio_read(dev, rp->phys[0], MII_LPA); + int mii_lpa = mdio_read(dev, rp->mii_if.phy_id, MII_LPA); int negotiated = mii_lpa & rp->mii_if.advertising; int duplex; @@ -1222,7 +1220,7 @@ printk(KERN_INFO "%s: Setting %s-duplex based on " "MII #%d link partner capability of %4.4x.\n", dev->name, duplex ? "full" : "half", - rp->phys[0], mii_lpa); + rp->mii_if.phy_id, mii_lpa); if (duplex) rp->chip_cmd |= CmdFDuplex; else @@ -1250,7 +1248,7 @@ rhine_check_duplex(dev); /* make IFF_RUNNING follow the MII status bit "Link established" */ - mii_status = mdio_read(dev, rp->phys[0], MII_BMSR); + mii_status = mdio_read(dev, rp->mii_if.phy_id, MII_BMSR); if ((mii_status & BMSR_LSTATUS) != (rp->mii_status & BMSR_LSTATUS)) { if (mii_status & BMSR_LSTATUS) netif_carrier_on(dev); @@ -1274,7 +1272,7 @@ printk(KERN_WARNING "%s: Transmit timed out, status %4.4x, PHY status " "%4.4x, resetting...\n", dev->name, readw(ioaddr + IntrStatus), - mdio_read(dev, rp->phys[0], MII_BMSR)); + mdio_read(dev, rp->mii_if.phy_id, MII_BMSR)); /* protect against concurrent rx interrupts */ disable_irq(rp->pdev->irq); @@ -1691,8 +1689,8 @@ printk(KERN_ERR "%s: MII status changed: " "Autonegotiation advertising %4.4x partner " "%4.4x.\n", dev->name, - mdio_read(dev, rp->phys[0], MII_ADVERTISE), - mdio_read(dev, rp->phys[0], MII_LPA)); + mdio_read(dev, rp->mii_if.phy_id, MII_ADVERTISE), + mdio_read(dev, rp->mii_if.phy_id, MII_LPA)); } if (intr_status & IntrStatsMax) { rp->stats.rx_crc_errors += readw(ioaddr + RxCRCErrs); From rl@hellgate.ch Wed Jun 16 06:19:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 06:20:47 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GDJlgi026486 for ; Wed, 16 Jun 2004 06:19:48 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD3003EDC1C; Tue, 15 Jun 2004 17:48:31 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id E8A9D21F343; Tue, 15 Jun 2004 19:48:30 +0200 (CEST) Date: Tue, 15 Jun 2004 19:48:30 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [2/9][PATCH 2.6] fix mc_filter on big-endian arch Message-ID: <20040615174830.GA11167@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 731 Lines: 17 A.J. from VIA Networking Technologies noticed that via-rhine is using cpu_to_le32() when preparing mc_filter hashes. This breaks Rhine hardware multicast filters on big-endian architectures. Signed-off-by: Roger Luethi --- 2.6-bk/drivers/net/via-rhine.c.orig 2004-06-06 18:03:21.323194221 +0200 +++ 2.6-bk/drivers/net/via-rhine.c 2004-06-06 18:05:22.137319854 +0200 @@ -1782,7 +1782,7 @@ i++, mclist = mclist->next) { int bit_nr = ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26; - mc_filter[bit_nr >> 5] |= cpu_to_le32(1 << (bit_nr & 31)); + mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31); } writel(mc_filter[0], ioaddr + MulticastFilter0); writel(mc_filter[1], ioaddr + MulticastFilter1); From jmorris@redhat.com Wed Jun 16 07:12:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 07:12:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GECQgi027892 for ; Wed, 16 Jun 2004 07:12:26 -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 i5GECEe1031082; Wed, 16 Jun 2004 10:12:14 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5GECD030209; Wed, 16 Jun 2004 10:12:14 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i5GECCZE030320; Wed, 16 Jun 2004 10:12:12 -0400 Date: Wed, 16 Jun 2004 10:12:12 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: kuznet@ms2.inr.ac.ru, , Subject: Re: IPsec and Path MTU In-Reply-To: <20040616121026.GA1169@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5986 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: 389 Lines: 16 On Wed, 16 Jun 2004, Herbert Xu wrote: > Now the problem with all this is that it looks pretty complicated. > So I'd like to hear from you that this is all unnecessary and that > one of you already has a solution for it all :) I think this sounds reasonable, and it is complicated (there's a reason why it hasn't been implemented yet). - James -- James Morris From mcr@sandelman.ottawa.on.ca Wed Jun 16 07:44:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 07:45:13 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GEimgi029586 for ; Wed, 16 Jun 2004 07:44:48 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i5GEhRP23767 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 16 Jun 2004 10:43:30 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5GEhM36028322 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Jun 2004 10:43:23 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5GEhJJ4028319; Wed, 16 Jun 2004 10:43:20 -0400 To: Herbert Xu cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU In-Reply-To: Message from Herbert Xu of "Wed, 16 Jun 2004 21:43:45 +1000." <20040616114345.GA1559@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <32703.1087311037@marajade.sandelman.ottawa.on.ca> <20040616114345.GA1559@gondor.apana.org.au> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 16 Jun 2004 10:43:19 -0400 Message-ID: <28318.1087396999@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 5987 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: 1910 Lines: 45 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Herbert" == Herbert Xu writes: >> The pmtu WG is considering changing how PMTU is done. You may >> want to look at draft-richardson-ipsec-fragment-XX.txt. This has >> not yet been adopted as a WG draft, because nobody is sure which >> WG should adopt it:-) Herbert> I'd say that we should get the stack to work with the hosts Herbert> that do send ICMP replies first, and then worry about those Herbert> that don't :) The proposal there is a compromise between what RFC1191 says, and what people in the field (and most IPsec implementations, because we get blamed) have done - it continues to send ICMP replies at all times that the old logic would usefully do, while not causing huge headaches that having ICMPs disappear causes. My opinion is that any solution which does not address the problem of ICMP blackholes is actually a step back because it causes things to intermittently fail. Right now, things just fail for big packets, period. That provides much large clue that there is a problem, which can be worked around. So, I'm agreeing with your :) -- we can tune the algorithm later, but let's make sure that we do it ASAP. - -- ] "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 iQCVAwUBQNBchIqHRg3pndX9AQFQWwQApGSYmkgs/4nogHYipee21MEannapT54m sAle7/fBIxUqIKZev8/RlrnVI+n8+e//AQBooeRF1ubmrd0LfajVd1TwwKvdE40S 47ysQrgSm3BHGet1xn+QLxYc3l9WumP7Ey+EkUKi22azcnjEvJ35r5crkMy2kVcg nALPB7hDwj0= =+nu7 -----END PGP SIGNATURE----- From rl@hellgate.ch Wed Jun 16 07:49:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 07:50:20 -0700 (PDT) Received: from mail6.bluewin.ch (mail6.bluewin.ch [195.186.4.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GEnegi030276 for ; Wed, 16 Jun 2004 07:49:41 -0700 Received: from k3.hellgate.ch (62.203.220.47) by mail6.bluewin.ch (Bluewin AG 7.0.028) id 40A46BD3003EDCB9; Tue, 15 Jun 2004 17:49:22 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id A5D1721F343; Tue, 15 Jun 2004 19:49:21 +0200 (CEST) Date: Tue, 15 Jun 2004 19:49:21 +0200 From: Roger Luethi To: Jeff Garzik , Andrew Morton Cc: netdev@oss.sgi.com Subject: [5/9][PATCH 2.6] Remove options, full_duplex parameters Message-ID: <20040615174921.GA11270@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 5988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 4022 Lines: 125 Nobody complained although media locking parameters were broken forever. They were sort of fixed recently, but the code is still in a bad shape. More seriously, the options/full_duplex stuff has fundamental design problems that have been discussed in-depth on the list (e.g. effect of hotplugging, nameif, suspend/resume). For those needing media locking with Linux 2.6+ via-rhine, ethtool(8) is the replacement. Signed-off-by: Roger Luethi --- orig/drivers/net/via-rhine.c +++ mod/drivers/net/via-rhine.c @@ -145,19 +145,10 @@ /* Select a backoff algorithm (Ethernet capture effect) */ static int backoff; -/* Used to pass the media type, etc. - Both 'options[]' and 'full_duplex[]' should exist for driver - interoperability. - The media type is usually passed in 'options[]'. - The default is autonegotiation for speed and duplex. - This should rarely be overridden. - Use option values 0x10/0x20 for 10Mbps, 0x100,0x200 for 100Mbps. - Use option values 0x10 and 0x100 for forcing half duplex fixed speed. - Use option values 0x20 and 0x200 for forcing full duplex operation. -*/ -#define MAX_UNITS 8 /* More are supported, limit only on options */ -static int options[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1}; -static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1}; +/* + * In case you are looking for 'options[]' or 'full_duplex[]', they + * are gone. Use ethtool(8) instead. + */ /* Maximum number of multicast addresses to filter (vs. rx-all-multicast). The Rhine has a 64 element 8390-like hash table. */ @@ -246,14 +237,10 @@ MODULE_PARM(debug, "i"); MODULE_PARM(rx_copybreak, "i"); MODULE_PARM(backoff, "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, "VIA Rhine maximum events handled per interrupt"); MODULE_PARM_DESC(debug, "VIA Rhine debug level (0-7)"); MODULE_PARM_DESC(rx_copybreak, "VIA Rhine copy breakpoint for copy-only-tiny-frames"); MODULE_PARM_DESC(backoff, "VIA Rhine: Bits 0-3: backoff algorithm"); -MODULE_PARM_DESC(options, "VIA Rhine: Bits 0-3: media type, bit 17: full duplex"); -MODULE_PARM_DESC(full_duplex, "VIA Rhine full duplex setting(s) (1)"); /* Theory of Operation @@ -671,7 +658,7 @@ { struct net_device *dev; struct rhine_private *rp; - int i, option, rc; + int i, rc; u8 pci_rev; u32 quirks; static int card_idx = -1; @@ -688,8 +675,6 @@ printk(version); #endif - card_idx++; - option = card_idx < MAX_UNITS ? options[card_idx] : 0; pci_read_config_byte(pdev, PCI_REVISION_ID, &pci_rev); io_size = 256; @@ -817,9 +802,6 @@ rp->mii_if.phy_id_mask = 0x1f; rp->mii_if.reg_num_mask = 0x1f; - if (dev->mem_start) - option = dev->mem_start; - /* The chip-specific entries in the device structure. */ dev->open = rhine_open; dev->hard_start_xmit = rhine_start_tx; @@ -841,20 +823,6 @@ if (rc) goto err_out_unmap; - /* The lower four bits are the media type. */ - if (option > 0) { - if (option & 0x220) - rp->mii_if.full_duplex = 1; - } - if (card_idx < MAX_UNITS && full_duplex[card_idx] > 0) - rp->mii_if.full_duplex = 1; - - if (rp->mii_if.full_duplex) { - printk(KERN_INFO "%s: Set to forced full duplex, " - "autonegotiation disabled.\n", dev->name); - rp->mii_if.force_media = 1; - } - printk(KERN_INFO "%s: VIA %s at 0x%lx, ", dev->name, name, #ifdef USE_MMIO @@ -890,21 +858,6 @@ } rp->mii_if.phy_id = phy_id; - /* Allow forcing the media type. */ - if (option > 0) { - if (option & 0x220) - rp->mii_if.full_duplex = 1; - if (option & 0x330) { - printk(KERN_INFO " Forcing %dMbs %s-duplex " - "operation.\n", - (option & 0x300 ? 100 : 10), - (option & 0x220 ? "full" : "half")); - mdio_write(dev, phy_id, MII_BMCR, - ((option & 0x300) ? 0x2000 : 0) | /* 100mbps? */ - ((option & 0x220) ? 0x0100 : 0)); /* Full duplex? */ - } - } - return 0; err_out_unmap: From jgarzik@pobox.com Wed Jun 16 08:03:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 08:04: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.12.10/8.12.9) with SMTP id i5GF3pgi030888 for ; Wed, 16 Jun 2004 08:03:51 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Babx7-0003FW-KD; Wed, 16 Jun 2004 16:03:49 +0100 Message-ID: <40D06148.5050602@pobox.com> Date: Wed, 16 Jun 2004 11:03:36 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [0/9] via-rhine: Major surgery References: <20040615174732.GA10241@k3.hellgate.ch> In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5989 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: 534 Lines: 18 Roger Luethi wrote: > This set of patches obsoletes all via-rhine patches for 2.6 that didn't > make it into 2.6.7-rc3-mm2. Most notable changes: I rewrote the media, > PHY, and link state handling and added WOL support for Rhine chips. > > Patches [1/9] and [2/9] are resends so you won't have to go hunt them > down before trying the rest. > > These patches need review and testing, especially from people with > WOL-capable hardware. Cool. I'll review and get into netdev-2.6 (and thus -mm) in the next 24-48 hrs... Jeff From gbritton@doomcom.org Wed Jun 16 08:28:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 08:28:16 -0700 (PDT) Received: from fog.sekrit.org (fog.sekrit.org [66.92.77.184]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GFSBgi004075 for ; Wed, 16 Jun 2004 08:28:11 -0700 Received: by fog.sekrit.org (Postfix, from userid 500) id 5D9318B4009; Wed, 16 Jun 2004 11:28:08 -0400 (EDT) Date: Wed, 16 Jun 2004 11:28:08 -0400 From: Gerald Britton To: Scott Feldman Cc: Gertjan van Wingerde , netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040616152808.GA6270@fog.sekrit.org> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> User-Agent: Mutt/1.4.1i X-archive-position: 5990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gbritton@doomcom.org Precedence: bulk X-list: netdev Content-Length: 1744 Lines: 47 A few comments below. On Wed, Jun 16, 2004 at 02:13:18AM -0700, Scott Feldman wrote: > +/* for getting/setting wireless settings */ > +struct ethtool_wx_cmd { > + u32 cmd; > + u16 nwid; /* Wireless network ID; 0 = disabled */ > + struct { > + u32 mantissa; > + u16 exponent; > + } freq; /* Operating frequency */ > + u32 mode; /* Operating mode (ETH_WX_MODE_xxx) */ > + u16 sens; /* Sensitivity threshold (-dBm) */ > + struct sockaddr wap; /* Register with access point */ > + /* auto = 00:00:00:00:00:00 */ > + char essid[32]; /* ESSID; any = NULL string */ This isn't sufficient as you can have \0 bytes in the ESSID so treating it as a null-terminated string is probably not ideal. Also the spec specifies 32 characters as a max, but the 802.11 management IE's could support upto 255 character essid's, this probably needs a little extra thought. > + u32 rate; /* Bit rate b/s; 0 = auto */ > + u16 rts; /* Smallest packet size for which */ > + /* the node sends RTS; 0 = off */ > + u16 frag; /* Maximum fragment size; 0 = no frag */ > + u16 tx_power; /* Transmit power in dBm */ > + struct { /* TODO: thit needs work */ > + u16 limit; > + u32 lifetime; /* usec */ > + } retry; /* MAC retransmission */ > + u32 sec_mode; /* Security mode (ETH_WX_SEC_MODE_xxx) */ > + char sec_key[32]; /* Security mode encryption key */ Similar here, is 32 characters worth of "key" enough here. > + /* TODO: add struct power */ > + u32 reserved[16]; > +}; Also a quick thought to settings many drivers have in their iwpriv commands such as operating modes .11b/.11a/.11g/auto. A survey of a bunch of drivers is probably worth doing to collect where the previous wireless extentions didn't really fit their needs. -- Gerald From jeezfrk-vger@jeezfrk.homeip.net Wed Jun 16 09:41:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 09:41:33 -0700 (PDT) Received: from jeezfrk.homeip.net (c-67-174-185-81.client.comcast.net [67.174.185.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GGfLgi006426 for ; Wed, 16 Jun 2004 09:41:21 -0700 Received: by jeezfrk.homeip.net (Postfix, from userid 501) id 8051926186; Wed, 16 Jun 2004 09:44:38 -0600 (MDT) Subject: live TCP connections run via iptables-intercepted packets?? From: Christopher Hassell To: netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: not usually very organized Date: Wed, 16 Jun 2004 09:44:38 -0600 Message-Id: <1087400678.6397.4.camel@lobotomus.homeip.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1-1mdk X-archive-position: 5991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeezfrk-vger@jeezfrk.homeip.net Precedence: bulk X-list: netdev Content-Length: 1823 Lines: 48 Hello, I would like to know if anyone has the data structures and call points which would allow use of the Linux TCP stack on its own (unhashed, packets and initiation supplied elsewhere) with timers going off as needed. The idea being a "transducer" to translate a stream of TCP data (normal TCP session) into a stream of UDP packets. Yes this changes an ordered reliable stream into an unordered and unreliable stream but this is made for tunnelling over a reliable link. (Latency is an issue, and TCP does NOT help itself with added latency). Consider it arbitrarily-addressed kernel-speed transparent proxying. NO I'd not prefer a userland solution via DNAT or QUEUE, because latency-reduction is the question and it's not too complex a concept to just change TCP data to UDP and back. How would it work for an end user you ask? It would essentially convert incoming TCP connections into identically structured (IP:IP port:port) UDP packets and vice versa. In the same way, on the far end, a UDP packet could initiate a kernel-socket's attempted connect() to the remote destination of the UDP packet. A zero-length UDP packet would close the connection in the stack and, yeah, no other TCP tricks could be controlled via the UDP stream. It requires that... 1) packets are intercepted and delivered via an IPTables target that routes all packets to the running TCP stack (not unlike the initial DNAT or SNAT packet does). 2) acks or data packets can be sent any fashion needed as long as they proceed to normal routing as their addr befits 3) no need for valid local IP address is needed 4) timing events are fed to the code somehow Is it reasonable? Very few modules use TCP that I can see, from inside the kernel. -- CH From davem@redhat.com Wed Jun 16 10:31:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 10:31:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GHVNgi008504 for ; Wed, 16 Jun 2004 10:31:24 -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 i5GHVDe1023000; Wed, 16 Jun 2004 13:31:13 -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 i5GHVD004697; Wed, 16 Jun 2004 13:31:13 -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 i5GHUunZ023500; Wed, 16 Jun 2004 13:30:56 -0400 Date: Wed, 16 Jun 2004 10:25:03 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NET] Clear dev refs in dst->child Message-Id: <20040616102503.190333a9.davem@redhat.com> In-Reply-To: <20040616112211.GA956@gondor.apana.org.au> References: <20040616112211.GA956@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5992 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: 26 Lines: 2 Applied, thanks Herbert. From vkondra@mail.ru Wed Jun 16 10:40:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 10:40:55 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GHepgi009042 for ; Wed, 16 Jun 2004 10:40:52 -0700 Received: from [212.179.249.119] (port=30933 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BaeOz-000AVK-00; Wed, 16 Jun 2004 21:40:47 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink Date: Wed, 16 Jun 2004 20:40:07 +0300 User-Agent: KMail/1.6.2 Cc: Gerald Britton , Scott Feldman , Gertjan van Wingerde References: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <20040616152808.GA6270@fog.sekrit.org> In-Reply-To: <20040616152808.GA6270@fog.sekrit.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406162040.12747.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5GHepgi009042 X-archive-position: 5993 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: 2935 Lines: 82 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 16 June 2004 18:28, Gerald Britton wrote: > A few comments below. > > On Wed, Jun 16, 2004 at 02:13:18AM -0700, Scott Feldman wrote: > > +/* for getting/setting wireless settings */ > > +struct ethtool_wx_cmd { > > + u32 cmd; > > + u16 nwid; /* Wireless network ID; 0 = disabled */ > > + struct { > > + u32 mantissa; > > + u16 exponent; > > + } freq; /* Operating frequency */ > > + u32 mode; /* Operating mode (ETH_WX_MODE_xxx) */ > > + u16 sens; /* Sensitivity threshold (-dBm) */ > > + struct sockaddr wap; /* Register with access point */ > > + /* auto = 00:00:00:00:00:00 */ > > + char essid[32]; /* ESSID; any = NULL string */ > > This isn't sufficient as you can have \0 bytes in the ESSID so treating it > as a null-terminated string is probably not ideal. Also the spec specifies > 32 characters as a max, but the 802.11 management IE's could support upto > 255 character essid's, this probably needs a little extra thought. ... And WiFi compliance tests include testing for ESSID with \0 and other non-printable characters in all places. Sure, ESSID length should be added. One byte is sufficient. In all places within MAC, it is used as "info element" like struct ie { u8 id; u8 length; u8 content[0]; }; Is it worth to keep it in this format? Other candidates to include: - - supported rates - - Channel width. In Japan, in addition to 20Mhz channels, there are 10Mzh ones. - - country information. Country code and Tx power limit per channel group - - there are 2 independent keys: unicast and mcast, each may belong to different suite (AES, TKIP, WEP...) - - TGe data: air access parameters per access category, list of TSPECs, whether STA uses aggregate schedule, whether STA uses APSD (automatic power save delivery) > > > + u32 rate; /* Bit rate b/s; 0 = auto */ > > + u16 rts; /* Smallest packet size for which */ > > + /* the node sends RTS; 0 = off */ > > + u16 frag; /* Maximum fragment size; 0 = no frag */ > > + u16 tx_power; /* Transmit power in dBm */ > > + struct { /* TODO: thit needs work */ > > + u16 limit; > > + u32 lifetime; /* usec */ > > + } retry; /* MAC retransmission */ > > + u32 sec_mode; /* Security mode (ETH_WX_SEC_MODE_xxx) */ > > + char sec_key[32]; /* Security mode encryption key */ > > Similar here, is 32 characters worth of "key" enough here. > > > + /* TODO: add struct power */ > > + u32 reserved[16]; > > +}; > > Also a quick thought to settings many drivers have in their iwpriv > commands such as operating modes .11b/.11a/.11g/auto. A survey of a bunch > of drivers is probably worth doing to collect where the previous wireless > extentions didn't really fit their needs. > > -- Gerald -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0IX8qxdj7mhC6o0RAu6pAJ9gZsba1Fv7PE4ELFZTr6Tj7KkgfQCgrwIw /H6eBtA6jETvx2N/YzhAvTw= =pOUh -----END PGP SIGNATURE----- From sfeldma@pobox.com Wed Jun 16 10:53:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 10:53:49 -0700 (PDT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GHrlgi009729 for ; Wed, 16 Jun 2004 10:53:47 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040616175346.KAIQ6671.out003.verizon.net@[192.168.0.79]>; Wed, 16 Jun 2004 12:53:46 -0500 Subject: Re: [RFC] Wireless extensions rethink From: Scott Feldman Reply-To: sfeldma@pobox.com To: Gerald Britton Cc: Gertjan van Wingerde , netdev@oss.sgi.com In-Reply-To: <20040616152808.GA6270@fog.sekrit.org> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <20040616152808.GA6270@fog.sekrit.org> Content-Type: text/plain Message-Id: <1087408417.25912.79.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 10:53:38 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [4.5.57.153] at Wed, 16 Jun 2004 12:53:46 -0500 X-archive-position: 5994 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: 1650 Lines: 40 On Wed, 2004-06-16 at 08:28, Gerald Britton wrote: > A few comments below. > [snip] > > + char essid[32]; /* ESSID; any = NULL string */ > > This isn't sufficient as you can have \0 bytes in the ESSID so treating it > as a null-terminated string is probably not ideal. Also the spec specifies > 32 characters as a max, but the 802.11 management IE's could support upto > 255 character essid's, this probably needs a little extra thought. Ok, how about u8 essid[32]; /* ESSID; any = all zeros */ On the size, include/linux/wireless.h has it defined as 32: /* Maximum size of the ESSID and NICKN strings */ #define IW_ESSID_MAX_SIZE 32 > [snip] > > + char sec_key[32]; /* Security mode encryption key */ > > Similar here, is 32 characters worth of "key" enough here. include/linux/wireless.h has it defined as 32: /* Maximum size of the encoding token in bytes */ #define IW_ENCODING_TOKEN_MAX 32 /* 256 bits (for now) */ > Also a quick thought to settings many drivers have in their iwpriv > commands such as operating modes .11b/.11a/.11g/auto. A survey of a bunch > of drivers is probably worth doing to collect where the previous wireless > extentions didn't really fit their needs. So far we've only looked at the standard settings, but you're right, we should move commonly used private settings over to the standard set. There are some drivers (i.e. prism54) that use module params that are duplicates of the standard settings. These need cleaning up as well. -scott From gwingerde@home.nl Wed Jun 16 10:55:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 10:56:01 -0700 (PDT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GHtsgi010100 for ; Wed, 16 Jun 2004 10:55:55 -0700 Received: from [213.51.128.132] (port=57296 helo=smtp1.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1Baedd-0002Ek-7k; Wed, 16 Jun 2004 19:55:53 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([212.120.112.51]:34374 helo=[192.168.14.1]) by smtp1.home.nl with esmtp (Exim 4.30) id 1Baedb-0000pM-OR; Wed, 16 Jun 2004 19:55:51 +0200 Message-ID: <40D08769.3070106@home.nl> Date: Wed, 16 Jun 2004 19:46:17 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 0.6 (X11/20040526) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sfeldma@pobox.com CC: netdev@oss.sgi.com, jkmaline@cc.hut.fi, jt@hpl.hp.com, jgarzik@pobox.com Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> In-Reply-To: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> 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: 5995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Content-Length: 8226 Lines: 210 Scott, I'm afraid that this isn't enough. I think we have to split up the various settings over multiple commands. If we add just two commands (one for GET and one for SET) we have to change the binary ioctl-interface every time a new setting arrives (e.g. see how new settings will be added due to WPA support. That solution just isn't future-proof. Jean, Jouni, Jeff: What are your thoughts about this? Therefore I suggest we combine some of the basic settings in one command, and try to keep other settings in separate commands (again logically coherent settings should be combined in 1 command). I'll work on that, but unfortunately I can't hardly do anything until the weekend. I agree that we should be able to remove the commit command if we are able to set multiple settings that belong together at the same time. BTW I agree with most of the points your making. We just have to make sure that we define an interface that is sane and is future-proof with respect to future changes. --- Gertjan. Scott Feldman wrote: > On Tue, 2004-06-15 at 09:39, Gertjan van Wingerde wrote: > >>Sounds like a good idea. I'll start refactoring my work towards that approach. Please bear >>with me for a couple of days and I'll post a draft patch for this. > > > Gertjan, > > 24 clock: see how this patch looks. > > It adds just two more ETHTOOL_[G|S]WSET commands to handle the get/set > of the wireless settings. This works just like ETHTOOL_[G|S]SET by > passing in/out a struct ethtool_wx_cmd that holds all of the wireless > settings. The idea is the application would get the settings from the > driver, let the user change one or more of the settings, and send all of > the settings back to the driver. The driver just resets all settings in > one shot. > > I tried to use the correct type for the various settings based on what > the drivers did (unwinding the iw_param and iw_point members). I > probably missed some details; please help. > > Some observations/opens: > > 1) This is not compatible with the current wireless extensions ioctl, so > iwconfig must be re-written to use ethtool -w. :( > 2) Note that wireless stats can just be moved into ETHTOOL_GSTATS. > 3) iw_range needs another ETHTOOL_GWRANGE, but it looks like there is > some duplication with ETHTOOL_GWSET, so I'm not sure what's left - would > you look into this? > 4) nick is cosmetic, so it's not included here. > 5) Individual events are not generated for things like setting ESSID and > NWID. Since all of these settings are now set in batch, there really is > just one event: wireless settings changed. Event needs to come from the > ethtool_ops->get_wx_settings() so it's generated regardless of UI. On > the other hand, is there any practical use for the event in the first > place? We don't have events for LAN drivers when speed/duplex change, > for example, do we? > 6) The whole commit strategy is useless to us now because settings are > always set in batch with ETHTOOL_GWSET. The driver does an implicit > commit after applying settings. > 7) We need a driver to prototype this against - I'm using ipw2100, but > it would be better to use something that's already in the kernel. > 8) We need ethtool app updates to add a -w option to set wireless > settings. > 9) ethtool DEVNAME would use either get_settings or get_wx_settings, > depending on which one was implemented in the driver. > 10) Not sure what to do with get/set scan. > > See if you can make some progress on these open issues. > > -scott > > ---------------- > > diff -Naurp linux-2.6.7-rc3-bk1/include/linux/ethtool.h linux-2.6.7-rc3-bk1-ethtool/include/linux/ethtool.h > --- linux-2.6.7-rc3-bk1/include/linux/ethtool.h 2004-05-09 19:32:26.000000000 -0700 > +++ linux-2.6.7-rc3-bk1-ethtool/include/linux/ethtool.h 2004-06-16 01:09:44.018094360 -0700 > @@ -250,6 +250,49 @@ struct ethtool_stats { > u64 data[0]; > }; > > +enum ethtool_wx_mode { > + ETH_WX_MODE_AUTO = 0, > + ETH_WX_MODE_ADHOC, > + ETH_WX_MODE_INFRA, > + ETH_WX_MODE_MASTER, > + ETH_WX_MODE_REPEATER, > + ETH_WX_MODE_SECOND, > + ETH_WX_MODE_MONITOR, > +}; > + > +enum ethtool_wx_sec_mode { > + ETH_WX_SEC_MODE_OPEN = 0, > + ETH_WX_SEC_MODE_RESTRICTED, > +}; > + > +/* for getting/setting wireless settings */ > +struct ethtool_wx_cmd { > + u32 cmd; > + u16 nwid; /* Wireless network ID; 0 = disabled */ > + struct { > + u32 mantissa; > + u16 exponent; > + } freq; /* Operating frequency */ > + u32 mode; /* Operating mode (ETH_WX_MODE_xxx) */ > + u16 sens; /* Sensitivity threshold (-dBm) */ > + struct sockaddr wap; /* Register with access point */ > + /* auto = 00:00:00:00:00:00 */ > + char essid[32]; /* ESSID; any = NULL string */ > + u32 rate; /* Bit rate b/s; 0 = auto */ > + u16 rts; /* Smallest packet size for which */ > + /* the node sends RTS; 0 = off */ > + u16 frag; /* Maximum fragment size; 0 = no frag */ > + u16 tx_power; /* Transmit power in dBm */ > + struct { /* TODO: thit needs work */ > + u16 limit; > + u32 lifetime; /* usec */ > + } retry; /* MAC retransmission */ > + u32 sec_mode; /* Security mode (ETH_WX_SEC_MODE_xxx) */ > + char sec_key[32]; /* Security mode encryption key */ > + /* TODO: add struct power */ > + u32 reserved[16]; > +}; > + > struct net_device; > > /* Some generic methods drivers may use in their ethtool_ops */ > @@ -293,6 +336,8 @@ int ethtool_op_set_tso(struct net_device > * get_strings: Return a set of strings that describe the requested objects > * phys_id: Identify the device > * get_stats: Return statistics about the device > + * get_wx_settings: Get device-specific wireless settings > + * set_wx_settings: Set device-specific wireless settings > * > * Description: > * > @@ -351,6 +396,8 @@ struct ethtool_ops { > int (*phys_id)(struct net_device *, u32); > int (*get_stats_count)(struct net_device *); > void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *); > + int (*get_wx_settings)(struct net_device *, struct ethtool_wx_cmd *); > + int (*set_wx_settings)(struct net_device *, struct ethtool_wx_cmd *); > }; > > /* CMDs currently supported */ > @@ -386,6 +433,8 @@ struct ethtool_ops { > #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ > #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ > #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ > +#define ETHTOOL_GWSET 0x00000020 /* Get wireless settings. */ > +#define ETHTOOL_SWSET 0x00000021 /* Set wireless settings. */ > > /* compatibility with older code */ > #define SPARC_ETH_GSET ETHTOOL_GSET > diff -Naurp linux-2.6.7-rc3-bk1/net/core/ethtool.c linux-2.6.7-rc3-bk1-ethtool/net/core/ethtool.c > --- linux-2.6.7-rc3-bk1/net/core/ethtool.c 2004-06-08 11:13:53.000000000 -0700 > +++ linux-2.6.7-rc3-bk1-ethtool/net/core/ethtool.c 2004-06-16 01:13:52.615301840 -0700 > @@ -645,6 +645,36 @@ static int ethtool_get_stats(struct net_ > return ret; > } > > +static int ethtool_get_wx_settings(struct net_device *dev, void __user *useraddr) > +{ > + struct ethtool_wx_cmd cmd = { ETHTOOL_GWSET }; > + int err; > + > + if (!dev->ethtool_ops->get_wx_settings) > + return -EOPNOTSUPP; > + > + err = dev->ethtool_ops->get_wx_settings(dev, &cmd); > + if (err < 0) > + return err; > + > + if (copy_to_user(useraddr, &cmd, sizeof(cmd))) > + return -EFAULT; > + return 0; > +} > + > +static int ethtool_set_wx_settings(struct net_device *dev, void __user *useraddr) > +{ > + struct ethtool_wx_cmd cmd; > + > + if (!dev->ethtool_ops->set_wx_settings) > + return -EOPNOTSUPP; > + > + if (copy_from_user(&cmd, useraddr, sizeof(cmd))) > + return -EFAULT; > + > + return dev->ethtool_ops->set_wx_settings(dev, &cmd); > +} > + > /* The main entry point in this file. Called from net/core/dev.c */ > > int dev_ethtool(struct ifreq *ifr) > @@ -730,6 +760,10 @@ int dev_ethtool(struct ifreq *ifr) > return ethtool_phys_id(dev, useraddr); > case ETHTOOL_GSTATS: > return ethtool_get_stats(dev, useraddr); > + case ETHTOOL_GWSET: > + return ethtool_get_wx_settings(dev, useraddr); > + case ETHTOOL_SWSET: > + return ethtool_set_wx_settings(dev, useraddr); > default: > return -EOPNOTSUPP; > } > > > From davem@redhat.com Wed Jun 16 11:21:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 11:21:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GILmgi011440 for ; Wed, 16 Jun 2004 11:21:48 -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 i5GILge1004337; Wed, 16 Jun 2004 14:21: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 i5GILg023005; Wed, 16 Jun 2004 14:21:42 -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 i5GILOfe005813; Wed, 16 Jun 2004 14:21:25 -0400 Date: Wed, 16 Jun 2004 11:15:31 -0700 From: "David S. Miller" To: Eric Dumazet Cc: ahu@ds9a.nl, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [DOCUMENTATION PATCH] Missing net sysctls, some fixed, rest flagged Message-Id: <20040616111531.6047bb40.davem@redhat.com> In-Reply-To: <40D006BF.7020002@cosmosbay.com> References: <20040609175242.GA13875@outpost.ds9a.nl> <20040615201912.691ffe35.davem@redhat.com> <40D006BF.7020002@cosmosbay.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5996 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: 412 Lines: 13 On Wed, 16 Jun 2004 10:37:19 +0200 Eric Dumazet wrote: > I dont agree with the 'TCP' word here : listen() system call is not tied > with TCP, isn't it ? > I would suggest : > > +somaxconn - INTEGER > + Limit of socket listen() backlog, known in userspace as SOMAXCONN. > + Defaults to 128. See also tcp_max_syn_backlog for additional tuning for TCP sockets. > + Works for me. Applied. From mcgrof@studorgs.rutgers.edu Wed Jun 16 11:31:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 11:31:07 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GIUxgi011948 for ; Wed, 16 Jun 2004 11:30:59 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id D838AF9D54; Wed, 16 Jun 2004 14:30:58 -0400 (EDT) Date: Wed, 16 Jun 2004 14:30:58 -0400 To: Denis Vlasenko Cc: Margit Schubert-While , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] GUPD (Grand Unified Prism54 Driver) Open discussion Message-ID: <20040616183058.GR6253@ruslug.rutgers.edu> Mail-Followup-To: Denis Vlasenko , Margit Schubert-While , Netdev , prism54-devel@prism54.org References: <5.1.0.14.2.20040615143603.02a40b48@pop.t-online.de> <20040616001111.GK6253@ruslug.rutgers.edu> <200406160937.50943.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZOudaV4lSIjFTlHv" Content-Disposition: inline In-Reply-To: <200406160937.50943.vda@port.imtp.ilyichevsk.odessa.ua> 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: 5997 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: 1218 Lines: 40 --ZOudaV4lSIjFTlHv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 16, 2004 at 09:37:50AM +0300, Denis Vlasenko wrote: > > * WDS - Umm someone on the list had mentioned they had used WDS > > successfully and had some patches (?) Are you still alive? Are you > > still working on this? >=20 > No promises, but I'd like to take a look at WDS, > since I just got another prism54. Awesome Denis. Can you document your finding and advances here: http://prism54.org/phpwiki/ under the WDS section? Feyd, I know you're also ontop of USB dev. Can you also update changes on the same page for USB support? I believe there is also someone on the lists interested in helping. If anyone wants to takle an ongoing addition please feel free to add info there. --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --ZOudaV4lSIjFTlHv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0JHiat1JN+IKUl4RArgTAKCmJW6RYRmKHa5iESvG5Mkgl0mOmwCcC/L2 MtZ+XopZYRK9oaG7wQodMZo= =k7zo -----END PGP SIGNATURE----- --ZOudaV4lSIjFTlHv-- From gbritton@doomcom.org Wed Jun 16 12:06:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 12:06:19 -0700 (PDT) Received: from fog.sekrit.org (fog.sekrit.org [66.92.77.184]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GJ6Dgi013298 for ; Wed, 16 Jun 2004 12:06:14 -0700 Received: by fog.sekrit.org (Postfix, from userid 500) id 73AAA8B4009; Wed, 16 Jun 2004 15:06:13 -0400 (EDT) Date: Wed, 16 Jun 2004 15:06:13 -0400 From: Gerald Britton To: Scott Feldman Cc: Gertjan van Wingerde , netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040616190613.GA25743@fog.sekrit.org> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <20040616152808.GA6270@fog.sekrit.org> <1087408417.25912.79.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1087408417.25912.79.camel@sfeldma-mobl2.dsl-verizon.net> User-Agent: Mutt/1.4.1i X-archive-position: 5999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gbritton@doomcom.org Precedence: bulk X-list: netdev Content-Length: 2722 Lines: 62 On Wed, Jun 16, 2004 at 10:53:38AM -0700, Scott Feldman wrote: > On Wed, 2004-06-16 at 08:28, Gerald Britton wrote: > > A few comments below. > > [snip] > > > + char essid[32]; /* ESSID; any = NULL string */ > > > > This isn't sufficient as you can have \0 bytes in the ESSID so treating it > > as a null-terminated string is probably not ideal. Also the spec specifies > > 32 characters as a max, but the 802.11 management IE's could support upto > > 255 character essid's, this probably needs a little extra thought. > > Ok, how about > > u8 essid[32]; /* ESSID; any = all zeros */ > > On the size, include/linux/wireless.h has it defined as 32: > > /* Maximum size of the ESSID and NICKN strings */ > #define IW_ESSID_MAX_SIZE 32 IMHO, this is a flaw in the current wireless extensions. Your idea doesn't provide any way to determine the actual size of the data. ssids of \0\0 and \0\0\0 differ. I like Vladimir Kondratiev's suggestion of defining things in terms of info elements (IE's). This is how they get encoded in the frames sent over the air. > > > + char sec_key[32]; /* Security mode encryption key */ > > > > Similar here, is 32 characters worth of "key" enough here. > > include/linux/wireless.h has it defined as 32: > > /* Maximum size of the encoding token in bytes */ > #define IW_ENCODING_TOKEN_MAX 32 /* 256 bits (for now) */ IMO, simply following the wireless extentions is probably the wrong way to approach this, there is the opportunity to redesign things to better fit the actual needs of a generic ieee 802.11 stack in the kernel, and of the existing and likely future drivers. The current wireless extentions in many areas attempt to be over generic with interfaces which I've never seen a device actually implement to others whre the API ends up limiting you (like the ssid and key setting here). > > Also a quick thought to settings many drivers have in their iwpriv > > commands such as operating modes .11b/.11a/.11g/auto. A survey of a bunch > > of drivers is probably worth doing to collect where the previous wireless > > extentions didn't really fit their needs. > > So far we've only looked at the standard settings, but you're right, we > should move commonly used private settings over to the standard set. > There are some drivers (i.e. prism54) that use module params that are > duplicates of the standard settings. These need cleaning up as well. > > -scott Yeah. a handful of examples i can think of off the top of my head: antenna selection (diversity), beacon intervals, roaming settings, promiscuous mode within a bssid vs. fully promiscous receive (this one is probably highly dependant on generic 802.11 stack support). -- Gerald From sfeldma@pobox.com Wed Jun 16 12:06:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 12:06:32 -0700 (PDT) Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GJ6Ugi013336 for ; Wed, 16 Jun 2004 12:06:30 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out004.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040616190629.RBWN1551.out004.verizon.net@[192.168.0.79]>; Wed, 16 Jun 2004 14:06:29 -0500 Subject: Re: [RFC] Wireless extensions rethink From: Scott Feldman Reply-To: sfeldma@pobox.com To: Gertjan van Wingerde Cc: netdev@oss.sgi.com, jkmaline@cc.hut.fi, jt@hpl.hp.com, jgarzik@pobox.com In-Reply-To: <40D08769.3070106@home.nl> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> Content-Type: text/plain Message-Id: <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 12:06:21 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [4.5.57.153] at Wed, 16 Jun 2004 14:06:28 -0500 X-archive-position: 6000 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: 1523 Lines: 33 On Wed, 2004-06-16 at 10:46, Gertjan van Wingerde wrote: > I'm afraid that this isn't enough. I think we have to split up the various settings over > multiple commands. If we add just two commands (one for GET and one for SET) we have to > change the binary ioctl-interface every time a new setting arrives (e.g. see how new > settings will be added due to WPA support. That solution just isn't future-proof. There is some reserved space at the bottom of the struct to add new commands. The question is: how many new commands are needed for the future? I think we need to be very careful in keeping the standard settings for wireless bounded. In fact, we should take a careful look at the standard settings already defined and really question their need. For example, do we really want to burden the user with the decision of whether they need to set a maximum fragment size? Or what the sensitivity threshold should be? The point is, we need to find the minimal set of settings to get the job done. So let's have this discussion first before getting back to the implementation details. What is the minimal set of settings to expose to the user[1]? I would group them into basic, advanced, and authentication. Which ones are read-only? What's new in the near future? Once we agree on that set, the implementation falls out. -scott [1] By user, I mean someone that's just trying to get their wireless device to attach to a network, but doesn't know the difference between 11b and 11g or the meaning of RTS. From kuznet@ms2.inr.ac.ru Wed Jun 16 12:40:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 12:40:10 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GJdxgi017807 for ; Wed, 16 Jun 2004 12:40:00 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id XAA30050; Wed, 16 Jun 2004 23:37:31 +0400 Date: Wed, 16 Jun 2004 23:37:31 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: "David S. Miller" , schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040616193731.GB29781@ms2.inr.ac.ru> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040614124402.GA28519@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 697 Lines: 18 Hello! > Alexey, if I've missed any subtle piece of logic there, please > scream :) The "logic" behind the check ("logic" is double quoted because of that comment) with dst_discard_out was to make release only on the second attempt to unregister. In the past unregister event used to be rebroadcast periodically until the unregister finally succeeds. Now logic is different, so this check really does not make sense. Anyway, the comment remains damn true and the place is still bug. It makes sense to think about waiting for at least one quiescent state after detaching the stale device from dst and real dev_put() it. Reference to RCU is not occasional, the job looks natural for it. Alexey From jgarzik@pobox.com Wed Jun 16 12:49:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 12:49:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GJnggi018324 for ; Wed, 16 Jun 2004 12:49:43 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BagPk-0002Gd-JL; Wed, 16 Jun 2004 20:49:40 +0100 Message-ID: <40D0A446.8010607@pobox.com> Date: Wed, 16 Jun 2004 15:49:26 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sfeldma@pobox.com CC: Gertjan van Wingerde , netdev@oss.sgi.com, jkmaline@cc.hut.fi, jt@hpl.hp.com Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> In-Reply-To: <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6002 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: 1169 Lines: 32 I apologize for not responding earlier... ethtool is the wrong direction for a few reasons, * I really should have done ethtool via netlink * We want to move away from pretending that 802.3 == 802.11, and using ethtool only serves to reinforce an association we don't want to make. "everything is ethernet" isn't really true :) About overall API design... When designing interfaces that the low-level drivers must implement, keep two things in mind: * locking, security checks, and ioctl marshalling/thunking should be done in common kernel code, not each hardware driver. * given that, each wireless hook (callback) should be purpose-specific -- which means each callback's arguments and return value vary, depending on the callback's purpose. iw_handler must be killed, because that forces more code than necessary to be in each low-level driver. The example to look at here is struct ethtool_ops, and net/core/ethtool.c. Low-level drivers should be implementing small, fine-grained hooks NOT raw ioctl handlers. In addition to fostering smaller hardware drivers, this insulates the driver interface from ABI changes to a certain degree. Jeff From DanE@aiinet.com Wed Jun 16 12:53:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 12:53:10 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GJr5gi018705 for ; Wed, 16 Jun 2004 12:53:06 -0700 Received: by AIMAIL1.ai.aiinet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jun 2004 15:53:13 -0400 Message-ID: From: "Eble, Dan" To: "'netdev@oss.sgi.com'" Subject: MTU of related devices Date: Wed, 16 Jun 2004 15:53:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 6003 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 Content-Length: 1634 Lines: 32 I have two devices, where the traffic transmitted into one is encapsulated and sent out the other (ethernet frames bridged over Cisco HDLC in my case), and the MTU of the underlying device needs to be large enough to accommodate the MTU of the encapsulated device plus its link layer header. What is the best way to handle this? I have thought of a few things. 0. Have the encapsulated device change the underlying device's MTU when necessary. I would like this if there were only one encapsulated device, but there could possibly be more. 1. Make both change_mtu() functions examine the other device's current MTU and return -EINVAL when the requested value does not meet the constraints. This is nice because it provides immediate feedback at the time of the problem. Its primary drawback is that it requires the MTUs to be changed in a certain order. 2. Don't constrain the MTUs in change_mtu(), but drop all packets sent to the encapsulated device when the MTU of the underlying device is too small for the encapsulated device. Dropping all packets is better than dropping only the ones that are too large, because it can not be overlooked by a lackadaisical admin who simply pings with a small packet to see if the link is working. I could either log a message, controlled by net_ratelimit(), or I could simply declare that MTU is one of the things to check when a link does not work. Is any of these, or a variation, officially preferred over the others? Thank you, -- Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| From kuznet@ms2.inr.ac.ru Wed Jun 16 12:59:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 12:59:04 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GJwxgi019183 for ; Wed, 16 Jun 2004 12:59:00 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id XAA30272; Wed, 16 Jun 2004 23:56:53 +0400 Date: Wed, 16 Jun 2004 23:56:53 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040616195653.GC29781@ms2.inr.ac.ru> References: <20040615124334.GA25164@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040615124334.GA25164@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 708 Lines: 22 Hello! > As it is, the MTU for any peer with an IPsec policy is determined > by the MTU of its dst->path. But this is wrong because it assigns > a single MTU to all hosts behind an IPsec gateway, even though their > paths may well diverge beyond the gateway. Each SA bundle referring to a dst has pmtu derived from pmtu of that dst. So, actually, I do not understand the question. If the policy uses the raw IP level path dst, it inherits this pmtu. Alexey PS. Broadcast: guys, please, tell someone to Herbert, my e-mail is banned at his server: ... while talking to arnor.apana.org.au.: >>> RCPT To: <<< 550 mail from 194.67.69.111 rejected: administrative prohibition From davem@redhat.com Wed Jun 16 13:16:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:16:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GKGIgi020368 for ; Wed, 16 Jun 2004 13:16:19 -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 i5GKG3e1000961; Wed, 16 Jun 2004 16:16: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 i5GKG3029257; Wed, 16 Jun 2004 16:16:03 -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 i5GKFj2f027144; Wed, 16 Jun 2004 16:15:45 -0400 Date: Wed, 16 Jun 2004 13:09:50 -0700 From: "David S. Miller" To: Alexey Kuznetsov Cc: herbert@gondor.apana.org.au, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040616130950.6aadde3c.davem@redhat.com> In-Reply-To: <20040616193731.GB29781@ms2.inr.ac.ru> References: <20040613121514.6b3c1c8a.davem@redhat.com> <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6005 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: 834 Lines: 23 On Wed, 16 Jun 2004 23:37:31 +0400 Alexey Kuznetsov wrote: > Anyway, the comment remains damn true and the place is still > bug. It makes sense to think about waiting for at least one quiescent > state after detaching the stale device from dst and real dev_put() it. > Reference to RCU is not occasional, the job looks natural for it. It seems a simple synchronize_kernel() would clear all the crap no? ===== net/core/dst.c 1.18 vs edited ===== --- 1.18/net/core/dst.c 2004-06-16 10:26:56 -07:00 +++ edited/net/core/dst.c 2004-06-16 13:10:37 -07:00 @@ -243,6 +243,8 @@ dst->ops->ifdown(dst, unregister); } while ((dst = dst->child) && dst->flags & DST_NOHASH && dst->dev == dev); + + synchronize_kernel(); } static int dst_dev_event(struct notifier_block *this, unsigned long event, void *ptr) From romieu@fr.zoreil.com Wed Jun 16 13:22:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:22:35 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GKMUgi020819 for ; Wed, 16 Jun 2004 13:22:32 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5GKMCon016523; Wed, 16 Jun 2004 22:22:12 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5GKMCZr016522; Wed, 16 Jun 2004 22:22:12 +0200 Date: Wed, 16 Jun 2004 22:22:12 +0200 From: Francois Romieu To: Jeff Garzik , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54] CVS -> bk tree update Message-ID: <20040616222212.A14792@electric-eye.fr.zoreil.com> References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> <20040616022008.GM6253@ruslug.rutgers.edu> <40CFBA24.7030307@pobox.com> <20040616051103.GN6253@ruslug.rutgers.edu> <20040616064303.GO6253@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040616064303.GO6253@ruslug.rutgers.edu>; from mcgrof@studorgs.rutgers.edu on Wed, Jun 16, 2004 at 02:43:03AM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 6006 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: 352 Lines: 13 Luis R. Rodriguez : [...] > > Ok 2.6.7 is out, we missed it. Now what, send a group of patches against > that then? Imho it would make sense to feed patch against -mm. Do you have something like a tarball of the cvs repository up to the point from which you have elaborated the 1898 lines diff against -mm ? -- Ueimor From kuznet@ms2.inr.ac.ru Wed Jun 16 13:26:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:26:03 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GKPxgi021230 for ; Wed, 16 Jun 2004 13:26:00 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id AAA30595; Thu, 17 Jun 2004 00:23:41 +0400 Date: Thu, 17 Jun 2004 00:23:41 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040616202341.GD29781@ms2.inr.ac.ru> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616121026.GA1169@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616121026.GA1169@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 1210 Lines: 33 Hello! > > So unless I'm missing something, we should get rid of dst->path and > > store the MTU in the xfrm dst's directly. Yes, this is absolutely true. BTW we talked about this already. The problem here is pure technical. In any case pmtu on path going through tunnel is _lower_ than dst_path() and has to be recalculated when dst_path() changes. Because we do not hold any back references for dst's using dst->path, we cannot do this actively. dst_path() is enough to do this. But it is definitely not enough when pmtu is lowered on some policies by another reasons. So, holding pmtu at all the dst's is necessary and we have to sync those mtus with dst_path instead using it directly. > Now the problem with all this is that it looks pretty complicated. I am afraid I still did not understand your troubles completely. Actually, the last time when we discussed this we had only one but _damn_ ugly problem. We have to remember original packet content to reply with ICMP correctly, when encapsulating. Is it possible that you are confused with this? We do send invalid ICMP_FRAG_NEEDED from ip_fragment. PMTU discovery will work only if we reply to original, not transofrmed packet. See? Alexey From jgarzik@pobox.com Wed Jun 16 13:31:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:31: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.12.10/8.12.9) with SMTP id i5GKV9gi021684 for ; Wed, 16 Jun 2004 13:31:10 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bah3s-0003LI-KU; Wed, 16 Jun 2004 21:31:08 +0100 Message-ID: <40D0ADFF.1040208@pobox.com> Date: Wed, 16 Jun 2004 16:30:55 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54] CVS -> bk tree update References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> <20040616022008.GM6253@ruslug.rutgers.edu> <40CFBA24.7030307@pobox.com> <20040616051103.GN6253@ruslug.rutgers.edu> <20040616064303.GO6253@ruslug.rutgers.edu> In-Reply-To: <20040616064303.GO6253@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6008 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: 363 Lines: 15 Luis R. Rodriguez wrote: > Jeff, > > Ok 2.6.7 is out, we missed it. Now what, send a group of patches against that then? Don't feel too bad, it was in release candidate status so any patches submitted would not have gone into 2.6.7 anyway (unless they were critical bug fixes). I'll reply to your other email after a yummy bowl of Ramen noodles... Jeff From kuznet@ms2.inr.ac.ru Wed Jun 16 13:40:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:40:36 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GKeVgi022218 for ; Wed, 16 Jun 2004 13:40:34 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id AAA30710; Thu, 17 Jun 2004 00:37:48 +0400 Date: Thu, 17 Jun 2004 00:37:48 +0400 From: Alexey Kuznetsov To: "David S. Miller" Cc: herbert@gondor.apana.org.au, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040616203748.GA30675@ms2.inr.ac.ru> References: <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616130950.6aadde3c.davem@redhat.com> User-Agent: Mutt/1.5.6i X-archive-position: 6009 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 746 Lines: 30 Hello! > > bug. It makes sense to think about waiting for at least one quiescent > > state after detaching the stale device from dst and real dev_put() it. > > Reference to RCU is not occasional, the job looks natural for it. > > It seems a simple synchronize_kernel() would clear all the > crap no? Sort of. I think it should happen after killing reference to dst->dev: + dst->dev = &loopback_dev; + dev_hold(&loopback_dev); but before dropping reference to dev: + dev_put(dev); So, I think it should look like: dst->dev = &loopback_dev; dev_hold(&loopback_dev); + synchronize_kernel(); dev_put(dev); (sorry, I still do not have Herbert's patch pulled) Alexey From davem@redhat.com Wed Jun 16 13:47:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:47:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GKlRgi022689 for ; Wed, 16 Jun 2004 13:47:28 -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 i5GKlDe1008730; Wed, 16 Jun 2004 16:47:13 -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 i5GKlC007083; Wed, 16 Jun 2004 16:47:13 -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 i5GKksWY007772; Wed, 16 Jun 2004 16:46:55 -0400 Date: Wed, 16 Jun 2004 13:47:11 -0700 From: "David S. Miller" To: Alexey Kuznetsov Cc: herbert@gondor.apana.org.au, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040616134711.499209c9.davem@redhat.com> In-Reply-To: <20040616203748.GA30675@ms2.inr.ac.ru> References: <20040613234142.GA32329@gondor.apana.org.au> <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6010 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: 414 Lines: 15 On Thu, 17 Jun 2004 00:37:48 +0400 Alexey Kuznetsov wrote: > Sort of. I think it should happen after killing reference to dst->dev: ... > but before dropping reference to dev: ... > So, I think it should look like: > > dst->dev = &loopback_dev; > dev_hold(&loopback_dev); > + synchronize_kernel(); > dev_put(dev); Perfect, that's what I put into my tree then, plus some comment. From davem@redhat.com Wed Jun 16 13:49:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 13:49:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GKnCgi023020 for ; Wed, 16 Jun 2004 13:49:13 -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 i5GKn5e1009089; Wed, 16 Jun 2004 16:49:05 -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 i5GKn5007565; Wed, 16 Jun 2004 16:49:05 -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 i5GKmlhf008462; Wed, 16 Jun 2004 16:48:48 -0400 Date: Wed, 16 Jun 2004 13:49:04 -0700 From: "David S. Miller" To: Alexey Kuznetsov Cc: herbert@gondor.apana.org.au, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-Id: <20040616134904.49b462ce.davem@redhat.com> In-Reply-To: <20040616202341.GD29781@ms2.inr.ac.ru> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616121026.GA1169@gondor.apana.org.au> <20040616202341.GD29781@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6011 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: 518 Lines: 11 On Thu, 17 Jun 2004 00:23:41 +0400 Alexey Kuznetsov wrote: > Actually, the last time when we discussed this we had only one > but _damn_ ugly problem. We have to remember original packet content > to reply with ICMP correctly, when encapsulating. Is it possible > that you are confused with this? We do send invalid ICMP_FRAG_NEEDED > from ip_fragment. PMTU discovery will work only if we reply to original, > not transofrmed packet. See? Yes, it seems we should finally implement this beast. From vkondra@mail.ru Wed Jun 16 14:01:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:01:31 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GL1Qgi023663 for ; Wed, 16 Jun 2004 14:01:27 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id D94AFDA9B4 for ; Thu, 17 Jun 2004 00:59:20 +0400 (MSD) Received: from [212.179.249.119] (port=23447 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BahU8-000Ivi-00; Thu, 17 Jun 2004 00:58:18 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: How device could assemble qdisc for self? Date: Wed, 16 Jun 2004 23:57:41 +0300 User-Agent: KMail/1.6.2 Cc: jamal MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200406162357.49366.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5GL1Qgi023663 X-archive-position: 6012 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: 1536 Lines: 51 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am a bit confused looking at qdisc related stuff. Could someone please point me to right documentation, code to look for etc? I'd like to employ NIC with many Tx DMA queues, designated for different types of traffic. Jamal pointed to qdiscs as a way to do it. My current idea is as following: I need to arrange the following qdisc structure: - - total 6 queues (FIFO) maintained; - - 4 queues get packets accordingly to 802.1D priority tags (some simple fixed mapping, actually those described in TGe - standard for wireless QoS) Table follows, but really it does not matter. 802.1D queue(access category) 1 AC_BK Background 2 AC_BK 0 AC_BE Best effort 3 AC_BE 4 AC_VI Video 5 AC_VI 6 AC_VO Voice 7 AC_VO - - 1 queue used for all bcast/mcast packets (wireless AP need it) - - 1 queue used for packets marked by application in some specific way (don't know how exactly, long story, next time) Each queue corresponds to one tx DMA queue within NIC. Each one should be stopped/started separately. Then, in hard_start_xmit, I will select proper DMA queue based on skb->priority. When DMA queue is full, I will stop corresponding qdisc. Does this structure make sense? Could it be done easier? Vladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0LRNqxdj7mhC6o0RAvaMAJ4kr7le3zZQbspb5biMsexbJSi/HwCgiwyJ gDn2m3VujWZuoGgOhWClwhI= =ygYp -----END PGP SIGNATURE----- From jgarzik@pobox.com Wed Jun 16 14:09:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:09:33 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GL9Rgi024187 for ; Wed, 16 Jun 2004 14:09:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bahew-0004vo-Tf; Wed, 16 Jun 2004 22:09:27 +0100 Message-ID: <40D0B6F9.7020600@pobox.com> Date: Wed, 16 Jun 2004 17:09:13 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54] CVS -> bk tree update References: <20040614191651.GC6253@ruslug.rutgers.edu> <40CE2754.1020109@pobox.com> <20040616022008.GM6253@ruslug.rutgers.edu> <40CFBA24.7030307@pobox.com> <20040616051103.GN6253@ruslug.rutgers.edu> In-Reply-To: <20040616051103.GN6253@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6014 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: 4845 Lines: 116 Luis R. Rodriguez wrote: > On Tue, Jun 15, 2004 at 11:10:28PM -0400, Jeff Garzik wrote: >>Sorry, no. You knew that split-up patches would be needed, once the >>initial driver merge is complete (which was complete before the most >>recent series of 17 patches). > > > Actually no. I wasn't aware of how netdev patches went upstream until > the driver got in and our first set of patches got rejected. After the > driver got in the kernel the first set of patches was just to get the > kernel tree up to speed with what *really* was current in our cvs tree > (remember Jean was the one who submitted the original patch). > > What occurred afterwards was more of a misunderstanding of what is > acceptable and what is not for patches for network driver projects. I > thought, since you had suggested to continue with the prism54 project, > and submit a patch for our next release. No one on our dev team or > lists knew any better or didn't say much to make us think otherwise. This is general Linux kernel development, nothing netdev specific about it (besides who the email goes to). The details are in Documentation/SubmittingPatches. Large "megapatches" are _always_ discouraged. The only normal case where large patches are accepted is when adding new drivers. >>This is one of the big downsides to developing in CVS, > > > for the kernel since what's mainly used by mantainers is > bitkeeper Nope. CVS specifically sucks above all other SCMs, including no-SCM-at-all :) "subversion" and "arch" are up-and-coming open source competitors to BitKeeper, that are already 1000 times better than cvs. I kept my kernel hacking in cvs for years (http://sf.net/projects/gkernel/) but I abandoned that before BitKeeper arrived, because CVS was simply the _wrong_ SCM for kernel development. CVS does not have a good idea of what a "changeset" is, it only knows about individual file revisions. CVS is a big fat hack :) But nothing else was free and remotely usable at the time, so it caught on. >>and it bites >>people again and again. > > > CVS is used as a project repository, not *the linux kernel repository*. It would > seem to me reasonable though that if a project is doing a good job in > making sure code gets tested, keeping a tight bugzilla, cvs daily > updates, a detailed changelog, and viewcvs, that a big patch sent out to > kernel mantainers for a new driver project release version would just be > accepted. Apparantly not and *this* is what sucks about using CVS -- the > fact these rules for small patches exist, and that the kernel uses a > different versioning system. And that's it. Versioning system is irrelevant, it's the lack of changeset support in CVS that hurts the most. >>Linux kernel development relies on split-up patches for review, testing, >> and narrowing down which patch in a series introduced a bug. There >>are real, engineering-related reasons we do things this way. > > > Don't get me wrong... I love this. I think that because of this is why > we have such a great kernel. The problem here was that there was > miscommunication between you, Jean, and us. The patch shouldn't have > been accepted to include the driver into the kernel until > our main project goals were completed. We then did not know the details > on followup procedures to update netdev drivers, nor were we told. Agreed, this was largely a problem of miscommunication. For my part, I simply assumed that you guys knew the standard kernel procedure (Documentation/SubmittingPatches), since the first two steps were successful: 1) submit driver, and 2) submit follow-up changes as small, broken-up patches > We've learned our lesson the hard way. Oh well. Just please warn others > submitting new drivers too -- submit until you think you only have small > changes left, and also integrate the driver by verifying first with the > mantainers (warn about patch policy, etc). We mainly need to make sure people read Documentation/SubmittingDrivers and Documentation/SubmittingPatches... > This also just makes me want to just consider using bitkeeper. What benefits are > there for our project, would we be able to get write access, and how > else would procedures change for us? Bitkeeper is de-centralized, designed for massively distributed development. The best way to answer your questions is to read Documentation/BK-usage/bk-kernel-howto.txt -- I wrote it, and it presents BitKeeper from a CVS point of view, for kernel hackers. Food for thought: There is no client/server in BitKeeper, each repository on disk it essentially its own branch. As to submitting changes via BitKeeper, here is an example of me sending changes to Linus: http://seclists.org/lists/linux-kernel/2003/Dec/1166.html (that email is almost completely auto-generated) Jeff From vkondra@mail.ru Wed Jun 16 14:09:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:09:26 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GL9Mgi024171 for ; Wed, 16 Jun 2004 14:09:23 -0700 Received: from [212.179.249.119] (port=49460 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1Bahe6-0005p8-00; Thu, 17 Jun 2004 01:09:19 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: How device could assemble qdisc for self? Date: Thu, 17 Jun 2004 00:07:53 +0300 User-Agent: KMail/1.6.2 Cc: jamal References: <200406162357.49366.vkondra@mail.ru> In-Reply-To: <200406162357.49366.vkondra@mail.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406170007.58652.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5GL9Mgi024171 X-archive-position: 6013 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: 1784 Lines: 56 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forget to mention, after these 6 qdiscs I described, there is round robin scheduler that do actually sends packets to hard_start_xmit. On Wednesday 16 June 2004 23:57, Vladimir Kondratiev wrote: > Hi, > I am a bit confused looking at qdisc related stuff. Could someone please > point me to right documentation, code to look for etc? > > I'd like to employ NIC with many Tx DMA queues, designated for different > types of traffic. Jamal pointed to qdiscs as a way to do it. > > My current idea is as following: > > I need to arrange the following qdisc structure: > > - total 6 queues (FIFO) maintained; > > - 4 queues get packets accordingly to 802.1D priority tags (some simple > fixed mapping, actually those described in TGe - standard for wireless QoS) > Table follows, but really it does not matter. > > 802.1D queue(access category) > 1 AC_BK Background > 2 AC_BK > 0 AC_BE Best effort > 3 AC_BE > 4 AC_VI Video > 5 AC_VI > 6 AC_VO Voice > 7 AC_VO > > - 1 queue used for all bcast/mcast packets (wireless AP need it) > > - 1 queue used for packets marked by application in some specific way > (don't know how exactly, long story, next time) > > Each queue corresponds to one tx DMA queue within NIC. Each one should be > stopped/started separately. Then, in hard_start_xmit, I will select proper > DMA queue based on skb->priority. When DMA queue is full, I will stop > corresponding qdisc. > > Does this structure make sense? Could it be done easier? > > Vladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0Lauqxdj7mhC6o0RAlGNAJ4m9ffMI2ZQ5t74rfVnRh5pVNfpIwCfWm0D aRk5Ox9agY1yjL6NzC8kOyI= =k8Eo -----END PGP SIGNATURE----- From jt@bougret.hpl.hp.com Wed Jun 16 14:17:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:18:02 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GLHmgi024994 for ; Wed, 16 Jun 2004 14:17:48 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 428508B48; Wed, 16 Jun 2004 13:50:15 -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 NAA07537; Wed, 16 Jun 2004 13:51:42 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BahMM-000720-00; Wed, 16 Jun 2004 13:50:14 -0700 Date: Wed, 16 Jun 2004 13:50:14 -0700 To: Scott Feldman Cc: Gertjan van Wingerde , netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040616205014.GB23617@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> 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: 6015 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: 563 Lines: 14 On Wed, Jun 16, 2004 at 12:06:21PM -0700, Scott Feldman wrote: > > For example, do we really want to burden the user with the decision of > whether they need to set a maximum fragment size? Or what the > sensitivity threshold should be? The point is, we need to find the > minimal set of settings to get the job done. For the record, those commands were added in 1997 for sensitivity and 1999 for frag/rts. For the card of those ancient time, setting those parameters was important, as the Access Point was not pushing them to the cards. Have fun... Jean From jt@bougret.hpl.hp.com Wed Jun 16 14:19:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:19:04 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GLIogi025225 for ; Wed, 16 Jun 2004 14:18:50 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 664BA1C07587; Wed, 16 Jun 2004 13:42:49 -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 NAA07387; Wed, 16 Jun 2004 13:44:16 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BahFA-00071l-00; Wed, 16 Jun 2004 13:42:48 -0700 Date: Wed, 16 Jun 2004 13:42:48 -0700 To: Gertjan van Wingerde Cc: sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040616204248.GA23617@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D08769.3070106@home.nl> 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: 6016 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: 3218 Lines: 73 On Wed, Jun 16, 2004 at 07:46:17PM +0200, Gertjan van Wingerde wrote: > > Scott, > > I'm afraid that this isn't enough. I think we have to split up the various > settings over > multiple commands. If we add just two commands (one for GET and one for > SET) we have to > change the binary ioctl-interface every time a new setting arrives (e.g. > see how new > settings will be added due to WPA support. That solution just isn't > future-proof. > > Jean, Jouni, Jeff: What are your thoughts about this? You are asking me what I think about throwing away the API I designed and restarting from scratch. You must be joking ;-) Furthermore, if you really want to redesign the API, then you don't want to ask the guy responsible of the first one to avoid its influence and avoid doing the same mistakes ;-) If you really want to have more background on my thoughts, please look at this thread : http://marc.theaimsgroup.com/?t=107835339400003&r=1&w=2 Seriously, these are my thoughts : o Backward/forward compatibility has always be my number one priority since 1996. There is many wireless drivers *NOT* in the kernel (see my web page) and many utilities using the current API. For example, both the Red-Hat configurator and the Debian installer link with libiw. So, it's not just about rewritting iwconfig. o Designing an API is not about choosing if you use multiple ioctls or a single ioctl, or another mechanism. I don't care about those details. Making choices will always make people unhappy. o I'm slow and lazy, but not opposed to changes, as long as they are well motivated and designed. Yeah, for WPA, I totally suck, but Jouni is going to save the day. I'm not opposed to fixing my mistakes, as long as it's painless for people using the API. o If you really want to improve Linux-802.11 support, we should focus first on the missing parts (in-kernel 802.11 framing and management), not redo the stuff that already works. o I don't want to get in your way, so don't expect much from me. If you can do a better job than me, then we all win. I also asked Jeff why he want to redesign the API, and in the end there was only two issues : 1) type-safe handler versus generic handler. I personally disagree with Jeff on that one. But, you can easilly fix it by offering wrapper to the current API : http://marc.theaimsgroup.com/?l=linux-netdev&m=107896289630224&w=2 2) The use of ioctls. I've created a patch to add RtNetlink support to the Wireless Extension API, and so far nobody has commented on this : http://marc.theaimsgroup.com/?l=linux-netdev&m=107846135617655&w=2 A more recent/functional version of this patch is on my web page. I'm not going to waste time on this if nobody cares. > I agree that we should be able to remove the commit > command if we are > able to set multiple settings that belong together at the same time. Setting that belong together is highly dependant on how the firware is written. With most cards, *all* setting belong together (check the Raylink driver if you have time). The commit command in current WE is optional. You don't like it, you don't use it. Are those the answer you were looking for, or did I miss something ? Have fun... Jean From cramerj@intel.com Wed Jun 16 14:25:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:25:06 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GLP2gi025744 for ; Wed, 16 Jun 2004 14:25:03 -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 i5G5VCfg023375; Wed, 16 Jun 2004 05:31:12 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5G5VRLE028647; Wed, 16 Jun 2004 05:31:30 GMT Received: from mini.jf.intel.com ([134.134.3.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061522302023639 ; Tue, 15 Jun 2004 22:30:20 -0700 Subject: [PATCH 1/1 2.4] e1000 management reset fix From: Jeb Cramer To: jgarzik@pobox.com, netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Jun 2004 21:41:30 -0700 Message-Id: <1087360890.12233.11.camel@mini> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 6017 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cramerj@intel.com Precedence: bulk X-list: netdev Content-Length: 3403 Lines: 123 * Resetting the adapter blew away management settings. So we save the important bits before performing a reset. ------------------------------------------------------- diff -Nuarp --- A/drivers/net/e1000/e1000.h +++ B/drivers/net/e1000/e1000.h @@ -197,6 +197,7 @@ struct e1000_adapter { uint32_t part_num; uint32_t wol; uint32_t smartspeed; + uint32_t en_mng_pt; uint16_t link_speed; uint16_t link_duplex; spinlock_t stats_lock; diff -Nuarp --- A/drivers/net/e1000/e1000_hw.c +++ B/drivers/net/e1000/e1000_hw.c @@ -265,6 +265,17 @@ e1000_set_mac_type(struct e1000_hw *hw) return -E1000_ERR_MAC_TYPE; } + switch(hw->mac_type) { + case e1000_82541: + case e1000_82547: + case e1000_82541_rev_2: + case e1000_82547_rev_2: + hw->asf_firmware_present = TRUE; + break; + default: + break; + } + return E1000_SUCCESS; } @@ -5189,3 +5200,27 @@ e1000_set_vco_speed(struct e1000_hw *hw) return E1000_SUCCESS; } +/****************************************************************************** + * Verifies the hardware needs to allow ARPs to be processed by the host + * + * hw - Struct containing variables accessed by shared code + * + * returns: - TRUE/FALSE + * + *****************************************************************************/ +uint32_t +e1000_enable_mng_pass_thru(struct e1000_hw *hw) +{ + uint32_t manc; + + if (hw->asf_firmware_present) { + manc = E1000_READ_REG(hw, MANC); + + if (!(manc & E1000_MANC_RCV_TCO_EN) || + !(manc & E1000_MANC_EN_MAC_ADDR_FILTER)) + return FALSE; + if ((manc & E1000_MANC_SMBUS_EN) && !(manc & E1000_MANC_ASF_EN)) + return TRUE; + } + return FALSE; +} diff -Nuarp --- A/drivers/net/e1000/e1000_hw.h +++ B/drivers/net/e1000/e1000_hw.h @@ -307,6 +307,7 @@ int32_t e1000_led_off(struct e1000_hw *h /* Adaptive IFS Functions */ /* Everything else */ +uint32_t e1000_enable_mng_pass_thru(struct e1000_hw *hw); void e1000_clear_hw_cntrs(struct e1000_hw *hw); void e1000_reset_adaptive(struct e1000_hw *hw); void e1000_update_adaptive(struct e1000_hw *hw); @@ -983,6 +984,7 @@ struct e1000_hw { e1000_ms_type master_slave; e1000_ms_type original_master_slave; e1000_ffe_config ffe_config_state; + uint32_t asf_firmware_present; unsigned long io_base; uint32_t phy_id; uint32_t phy_revision; diff -Nuarp --- A/drivers/net/e1000/e1000_main.c +++ B/drivers/net/e1000/e1000_main.c @@ -299,7 +299,7 @@ e1000_down(struct e1000_adapter *adapter void e1000_reset(struct e1000_adapter *adapter) { - uint32_t pba; + uint32_t pba, manc; /* Repartition Pba for greater than 9k mtu * To take effect CTRL.RST is required. */ @@ -341,6 +341,12 @@ 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); + } } /** @@ -483,6 +489,8 @@ 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 shemminger@osdl.org Wed Jun 16 14:30:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:31:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GLUugi026163 for ; Wed, 16 Jun 2004 14:30: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 i5GLUgr21887; Wed, 16 Jun 2004 14:30:45 -0700 Date: Wed, 16 Jun 2004 14:30:42 -0700 From: Stephen Hemminger To: MIke Phillips Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH 2.6.7] TMS380 needs firmware loader Message-Id: <20040616143042.5c295fa3@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: 6018 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: 16 This driver calls request_firmware so firmware loader it looks like it needs the firmware loader. Build tested only. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/tokenring/Kconfig b/drivers/net/tokenring/Kconfig --- a/drivers/net/tokenring/Kconfig 2004-06-16 14:28:48 -07:00 +++ b/drivers/net/tokenring/Kconfig 2004-06-16 14:28:48 -07:00 @@ -85,6 +85,7 @@ config TMS380TR tristate "Generic TMS380 Token Ring ISA/PCI adapter support" depends on TR && (PCI || ISA) + select FW_LOADER ---help--- This driver provides generic support for token ring adapters based on the Texas Instruments TMS380 series chipsets. This From jgarzik@pobox.com Wed Jun 16 14:36:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 14:36: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.12.10/8.12.9) with SMTP id i5GLaggi026559 for ; Wed, 16 Jun 2004 14:36:43 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bai5J-0005Fv-I3; Wed, 16 Jun 2004 22:36:41 +0100 Message-ID: <40D0BD5B.201@pobox.com> Date: Wed, 16 Jun 2004 17:36:27 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> In-Reply-To: <20040616204248.GA23617@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6019 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: 1694 Lines: 44 Jean Tourrilhes wrote: > Seriously, these are my thoughts : > o Backward/forward compatibility has always be my number one > priority since 1996. There is many wireless drivers *NOT* in the > kernel (see my web page) and many utilities using the current API. For > example, both the Red-Hat configurator and the Debian installer link > with libiw. So, it's not just about rewritting iwconfig. This is something on which we'll have to agree to disagree. In Linux we are free to improve the APIs :) > I also asked Jeff why he want to redesign the API, and in the > end there was only two issues : > 1) type-safe handler versus generic handler. I personally > disagree with Jeff on that one. But, you can easilly fix it by > offering wrapper to the current API : > http://marc.theaimsgroup.com/?l=linux-netdev&m=107896289630224&w=2 I think I explained myself better, in the recent post in this thread. Such a wrapper does nothing to move the locking, ioctl marshalling, and security checks out of the drivers. ethtool_ops and net/core/ethtool.c were quantum-leap improvements over the ethtool handling code that existed to that point. Wireless needs to make the same quantum leap. > 2) The use of ioctls. I've created a patch to add RtNetlink > support to the Wireless Extension API, and so far nobody has commented > on this : > http://marc.theaimsgroup.com/?l=linux-netdev&m=107846135617655&w=2 > A more recent/functional version of this patch is on my web > page. I'm not going to waste time on this if nobody cares. Well, I liked the patch at least :) Take your patch, add new 'struct wireless_ops', convert existing wireless handlers, and we're good to go :) Jeff From shemminger@osdl.org Wed Jun 16 15:22:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 15:22:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GMMhgi027941 for ; Wed, 16 Jun 2004 15:22:43 -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 i5GMLqr32046; Wed, 16 Jun 2004 15:21:52 -0700 Date: Wed, 16 Jun 2004 15:21:51 -0700 From: Stephen Hemminger To: "Venkatesan, Ganesh" Cc: "cramerj" , "Ronciak, John" , "Jeff Garzik" , netdev@oss.sgi.com Subject: [PATCH 2.6.7] e1000 sparse cleanup Message-Id: <20040616152151.0723c468@dell_ss3.pdx.osdl.net> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0158A1CD@orsmsx408> 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: 6020 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: 6271 Lines: 205 The following gets rid of warnings from sparse checking tool. It doesn't like "#if X" when "#ifdef X" is intended declaring inline functions before they are used. -------- diff -Nru a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h --- a/drivers/net/e1000/e1000.h 2004-06-16 15:18:09 -07:00 +++ b/drivers/net/e1000/e1000.h 2004-06-16 15:18:09 -07:00 @@ -82,7 +82,7 @@ #include "e1000_hw.h" -#if DBG +#ifdef DBG #define E1000_DBG(args...) printk(KERN_DEBUG "e1000: " args) #else #define E1000_DBG(args...) diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2004-06-16 15:18:09 -07:00 +++ b/drivers/net/e1000/e1000_main.c 2004-06-16 15:18:09 -07:00 @@ -132,8 +132,6 @@ 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); -static inline void e1000_irq_disable(struct e1000_adapter *adapter); -static inline void e1000_irq_enable(struct e1000_adapter *adapter); static irqreturn_t e1000_intr(int irq, void *data, struct pt_regs *regs); static boolean_t e1000_clean_tx_irq(struct e1000_adapter *adapter); #ifdef CONFIG_E1000_NAPI @@ -150,9 +148,6 @@ void set_ethtool_ops(struct net_device *netdev); static void e1000_enter_82542_rst(struct e1000_adapter *adapter); static void e1000_leave_82542_rst(struct e1000_adapter *adapter); -static inline void e1000_rx_checksum(struct e1000_adapter *adapter, - struct e1000_rx_desc *rx_desc, - struct sk_buff *skb); static void e1000_tx_timeout(struct net_device *dev); static void e1000_tx_timeout_task(struct net_device *dev); static void e1000_smartspeed(struct e1000_adapter *adapter); @@ -206,6 +201,35 @@ module_param(debug, int, 0); MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); + +/** + * 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(adapter->pdev->irq); +} + +/** + * 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_init_module - Driver Registration Routine * @@ -2047,34 +2071,6 @@ } /** - * 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(adapter->pdev->irq); -} - -/** - * 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_intr - Interrupt Handler * @irq: interrupt number * @data: pointer to a network interface device structure @@ -2219,6 +2215,41 @@ } /** + * 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, * @adapter: board private structure **/ @@ -2573,40 +2604,6 @@ 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((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) diff -Nru a/drivers/net/e1000/e1000_osdep.h b/drivers/net/e1000/e1000_osdep.h --- a/drivers/net/e1000/e1000_osdep.h 2004-06-16 15:18:09 -07:00 +++ b/drivers/net/e1000/e1000_osdep.h 2004-06-16 15:18:09 -07:00 @@ -63,7 +63,7 @@ #define MSGOUT(S, A, B) printk(KERN_DEBUG S "\n", A, B) -#if DBG +#ifdef DBG #define DEBUGOUT(S) printk(KERN_DEBUG S "\n") #define DEBUGOUT1(S, A...) printk(KERN_DEBUG S "\n", A) #else From sfeldma@pobox.com Wed Jun 16 15:25:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 15:25:31 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GMPQgi028250 for ; Wed, 16 Jun 2004 15:25:26 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out001.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040616222525.OYBJ1464.out001.verizon.net@[192.168.0.79]>; Wed, 16 Jun 2004 17:25:25 -0500 Subject: Re: [RFC] Wireless extensions rethink From: Scott Feldman Reply-To: sfeldma@pobox.com To: Jeff Garzik , Gertjan van Wingerde Cc: netdev@oss.sgi.com, jkmaline@cc.hut.fi, jt@hpl.hp.com In-Reply-To: <40D0A446.8010607@pobox.com> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> <40D0A446.8010607@pobox.com> Content-Type: text/plain Message-Id: <1087424716.3351.60.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 15:25:17 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [4.5.57.153] at Wed, 16 Jun 2004 17:25:25 -0500 X-archive-position: 6021 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: 1574 Lines: 38 On Wed, 2004-06-16 at 12:49, Jeff Garzik wrote: > I apologize for not responding earlier... > > ethtool is the wrong direction for a few reasons, > * I really should have done ethtool via netlink > * We want to move away from pretending that 802.3 == 802.11, and using > ethtool only serves to reinforce an association we don't want to make. > "everything is ethernet" isn't really true :) Ok, then Gertjan was on track with his earlier post introducing wlantool_ops. Scratch the ethtool idea, my bad. Gertjan, can we make the wlantool_ops more purpose-specific as Jeff suggests? struct wlantool_ops { int (*commit)(struct net_device *); void (*get_name)(struct net_device *, struct wlantool_name *); - int (*get_nwid)(struct net_device *, struct wlantool_param *); - int (*set_nwid)(struct net_device *, struct wlantool_param *); + u16 (*get_nwid)(struct net_device *); + void (*set_nwid)(struct net_device *, u16); int (*get_freq)(struct net_device *, struct wlantool_freq *); int (*set_freq)(struct net_device *, struct wlantool_freq *); - int (*get_mode)(struct net_device *, struct wlantool_mode *); - int (*set_mode)(struct net_device *, struct wlantool_mode *); - int (*get_sens)(struct net_device *, struct wlantool_param *); - int (*set_sens)(struct net_device *, struct wlantool_param *); + u32 (*get_mode)(struct net_device *); + void (*set_mode)(struct net_device *, u32); + u16 (*get_sens)(struct net_device *); + void (*set_sens)(struct net_device *, u16); }; -scott From shemminger@osdl.org Wed Jun 16 15:29:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 15:29:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GMTsgi028693 for ; Wed, 16 Jun 2004 15:29:54 -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 i5GMTfr00396; Wed, 16 Jun 2004 15:29:41 -0700 Date: Wed, 16 Jun 2004 15:29:41 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6.7] sparse annotation of csum_and_copy_to_user Message-Id: <20040616152941.554fc23f@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: 6022 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: 3707 Lines: 90 csum_and_copy_to_user acts like copy_to_user so it needs annotations to get rid of several sparse warnings. diff -Nru a/include/asm-i386/checksum.h b/include/asm-i386/checksum.h --- a/include/asm-i386/checksum.h 2004-06-16 15:24:33 -07:00 +++ b/include/asm-i386/checksum.h 2004-06-16 15:24:33 -07:00 @@ -172,8 +172,10 @@ * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -static __inline__ unsigned int csum_and_copy_to_user(const char *src, char *dst, - int len, int sum, int *err_ptr) +static __inline__ unsigned int csum_and_copy_to_user(const char *src, + char __user *dst, + int len, int sum, + int *err_ptr) { if (access_ok(VERIFY_WRITE, dst, len)) return csum_partial_copy_generic(src, dst, len, sum, NULL, err_ptr); diff -Nru a/include/asm-mips/checksum.h b/include/asm-mips/checksum.h --- a/include/asm-mips/checksum.h 2004-06-16 15:24:33 -07:00 +++ b/include/asm-mips/checksum.h 2004-06-16 15:24:33 -07:00 @@ -41,7 +41,8 @@ * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -static inline unsigned int csum_and_copy_to_user (const char *src, char *dst, +static inline unsigned int csum_and_copy_to_user (const char *src, + char __user *dst, int len, int sum, int *err_ptr) { diff -Nru a/include/asm-parisc/checksum.h b/include/asm-parisc/checksum.h --- a/include/asm-parisc/checksum.h 2004-06-16 15:24:33 -07:00 +++ b/include/asm-parisc/checksum.h 2004-06-16 15:24:33 -07:00 @@ -191,8 +191,10 @@ * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -static __inline__ unsigned int csum_and_copy_to_user (const char *src, char *dst, - int len, int sum, int *err_ptr) +static __inline__ unsigned int csum_and_copy_to_user (const char *src, + char __user *dst, + int len, int sum, + int *err_ptr) { /* code stolen from include/asm-mips64 */ sum = csum_partial(src, len, sum); diff -Nru a/include/asm-sh/checksum.h b/include/asm-sh/checksum.h --- a/include/asm-sh/checksum.h 2004-06-16 15:24:33 -07:00 +++ b/include/asm-sh/checksum.h 2004-06-16 15:24:33 -07:00 @@ -201,8 +201,10 @@ * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -static __inline__ unsigned int csum_and_copy_to_user (const char *src, char *dst, - int len, int sum, int *err_ptr) +static __inline__ unsigned int csum_and_copy_to_user (const char *src, + char __user *dst, + int len, int sum, + int *err_ptr) { if (access_ok(VERIFY_WRITE, dst, len)) return csum_partial_copy_generic(src, dst, len, sum, NULL, err_ptr); diff -Nru a/include/asm-sparc/checksum.h b/include/asm-sparc/checksum.h --- a/include/asm-sparc/checksum.h 2004-06-16 15:24:33 -07:00 +++ b/include/asm-sparc/checksum.h 2004-06-16 15:24:33 -07:00 @@ -91,7 +91,7 @@ } static inline unsigned int -csum_partial_copy_to_user(const char *src, char *dst, int len, +csum_partial_copy_to_user(const char *src, char __user *dst, int len, unsigned int sum, int *err) { if (!access_ok (VERIFY_WRITE, dst, len)) { diff -Nru a/include/asm-sparc64/checksum.h b/include/asm-sparc64/checksum.h --- a/include/asm-sparc64/checksum.h 2004-06-16 15:24:33 -07:00 +++ b/include/asm-sparc64/checksum.h 2004-06-16 15:24:33 -07:00 @@ -66,8 +66,9 @@ */ #define HAVE_CSUM_COPY_USER extern unsigned int csum_partial_copy_user_sparc64(const char *src, char *dst, int len, unsigned int sum); + static __inline__ unsigned int -csum_and_copy_to_user(const char *src, char *dst, int len, +csum_and_copy_to_user(const char *src, char __user *dst, int len, unsigned int sum, int *err) { __asm__ __volatile__ ("stx %0, [%%sp + 0x7ff + 128]" From jt@bougret.hpl.hp.com Wed Jun 16 15:33:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 15:33:24 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GMXHgi029091 for ; Wed, 16 Jun 2004 15:33:17 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 4308314ABB; Wed, 16 Jun 2004 15:33:17 -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 PAA10038; Wed, 16 Jun 2004 15:34:44 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Baiy4-0007oX-00; Wed, 16 Jun 2004 15:33:16 -0700 Date: Wed, 16 Jun 2004 15:33:16 -0700 To: Jeff Garzik Cc: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040616223316.GA29618@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D0BD5B.201@pobox.com> 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: 6023 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: 2125 Lines: 51 On Wed, Jun 16, 2004 at 05:36:27PM -0400, Jeff Garzik wrote: > > This is something on which we'll have to agree to disagree. > > In Linux we are free to improve the APIs :) Well, this is where I wish system apps were strongly linked with the kernel as it is the case in *BSD. They don't have the headacke of backward/forward compatibility that we have. > > I also asked Jeff why he want to redesign the API, and in the > >end there was only two issues : > > 1) type-safe handler versus generic handler. I personally > >disagree with Jeff on that one. But, you can easilly fix it by > >offering wrapper to the current API : > > http://marc.theaimsgroup.com/?l=linux-netdev&m=107896289630224&w=2 > > I think I explained myself better, in the recent post in this thread. > Such a wrapper does nothing to move the locking, ioctl marshalling, and > security checks out of the drivers. The iw_handler already take care of the net locking, security check, and most of the ioctl marshalling. What the driver has to take care is only the remaining of marshalling and driver locking. I think you did not understood my idea at all. If you build a set of generic wrappers and hook them in the iw_handler table, you could trivially add the features you feel are missing into those wrappers. Those wrappers would expose whatever API you choose to the driver, call your struct wireless_ops for example. > > 2) The use of ioctls. I've created a patch to add RtNetlink > >support to the Wireless Extension API, and so far nobody has commented > >on this : > > http://marc.theaimsgroup.com/?l=linux-netdev&m=107846135617655&w=2 > > A more recent/functional version of this patch is on my web > >page. I'm not going to waste time on this if nobody cares. > > Well, I liked the patch at least :) Ok, I'll try to resume work on that, after I manage WPA. I still have issues with the RtNetlink API which was not designed to perform individual GET requests, and this make the code a bit tricky. I also want to totally remove the useless pointer from this API, but need a way to do that transparently. > Jeff Have fun... Jean From sfeldma@pobox.com Wed Jun 16 15:48:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 15:48:50 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GMmkgi029725 for ; Wed, 16 Jun 2004 15:48:46 -0700 Received: from [192.168.0.79] ([4.5.57.153]) by out005.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040616224845.YNWU3910.out005.verizon.net@[192.168.0.79]>; Wed, 16 Jun 2004 17:48:45 -0500 Subject: Re: [RFC] Wireless extensions rethink From: Scott Feldman Reply-To: sfeldma@pobox.com To: jt@hpl.hp.com Cc: Gertjan van Wingerde , netdev@oss.sgi.com, jkmaline@cc.hut.fi In-Reply-To: <20040616204248.GA23617@bougret.hpl.hp.com> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> Content-Type: text/plain Message-Id: <1087426116.3351.78.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 15:48:37 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [4.5.57.153] at Wed, 16 Jun 2004 17:48:44 -0500 X-archive-position: 6024 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: 562 Lines: 13 On Wed, 2004-06-16 at 13:42, Jean Tourrilhes wrote: > You are asking me what I think about throwing away the API I > designed and restarting from scratch. You must be joking ;-) > Furthermore, if you really want to redesign the API, then you > don't want to ask the guy responsible of the first one to avoid its > influence and avoid doing the same mistakes ;-) This is more about bringing the wireless extensions in-line with other APIs in the kernel, not trying to fix mistakes. Your advise and guidance would be much appreciated in this process. -scott From jgarzik@pobox.com Wed Jun 16 16:06:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 16:06:33 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GN6Rgi030436 for ; Wed, 16 Jun 2004 16:06:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BajUA-0007Yq-TD; Thu, 17 Jun 2004 00:06:27 +0100 Message-ID: <40D0D265.3070804@pobox.com> Date: Wed, 16 Jun 2004 19:06:13 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> In-Reply-To: <20040616223316.GA29618@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6025 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: 1709 Lines: 40 Jean Tourrilhes wrote: > I think you did not understood my idea at all. > If you build a set of generic wrappers and hook them in the > iw_handler table, you could trivially add the features you feel are > missing into those wrappers. Those wrappers would expose whatever API > you choose to the driver, call your struct wireless_ops for example. That doesn't help anything. Wrappers add code, while not solving the following problems... You want to expose a _specific_, fine-grained API to the driver. That is by definition the smallest interface one can design for the low-level driver. Anything else requires "additional work" -- from simple type-casting to real code. The three major problems of the current WE iw_handler interface specifically are, 1) uses array, rather than a structure of function pointers. This makes assignment of values _very_ easy to screw up. 2) type-opaque interfaces break C compiler pointer analysis. This prevents alias optimization from working well, and also breaks checkers like the Stanford checker and sparse. C gave the world a type system, we should use it. :) 3) Uses and stores offsets to driver-private structures in generic code (iw_handler_def). See #2 for pointer chasing/aliasing problems related to doing stuff like this. Further, this is a massive layer / object lifetime violation. The generic/core code should never need to know about a structure declared in a low-level driver. That's backwards from the way information should flow. It's not Jeff's weird personal preference that iw_handler be killed... type-opaque interfaces cause real problems. A good C programmer should very, very rarely use type-casting. Jeff From herbert@gondor.apana.org.au Wed Jun 16 16:14:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 16:14:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GNE2gi031091 for ; Wed, 16 Jun 2004 16:14: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 1Bajap-0001j3-00; Thu, 17 Jun 2004 09:13:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bajan-0001Ux-00; Thu, 17 Jun 2004 09:13:17 +1000 Date: Thu, 17 Jun 2004 09:13:17 +1000 To: Alexey Kuznetsov Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040616231317.GA5742@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616195653.GC29781@ms2.inr.ac.ru> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6026 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: 788 Lines: 19 On Wed, Jun 16, 2004 at 11:56:53PM +0400, Alexey Kuznetsov wrote: > > Each SA bundle referring to a dst has pmtu derived from pmtu > of that dst. So, actually, I do not understand the question. > If the policy uses the raw IP level path dst, it inherits this pmtu. The problem is that each bundle can have only one PMTU. But there can be an arbitrary number of paths over each bundle. > ... while talking to arnor.apana.org.au.: > >>> RCPT To: > <<< 550 mail from 194.67.69.111 rejected: administrative prohibition Sorry, should be fixed 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 herbert@gondor.apana.org.au Wed Jun 16 16:14:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 16:14:45 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GNEcgi031266 for ; Wed, 16 Jun 2004 16:14: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 1BajbP-0001ib-00; Thu, 17 Jun 2004 09:13:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BajZO-0001UK-00; Thu, 17 Jun 2004 09:11:50 +1000 From: Herbert Xu To: kuznet@ms2.inr.ac.ru (Alexey Kuznetsov) Subject: Re: IPsec and Path MTU Cc: herbert@gondor.apana.org.au, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040616202341.GD29781@ms2.inr.ac.ru> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.25-1-686-smp (i686)) Message-Id: Date: Thu, 17 Jun 2004 09:11:50 +1000 X-archive-position: 6027 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: 2892 Lines: 75 Alexey Kuznetsov wrote: > > So, holding pmtu at all the dst's is necessary and we have to sync > those mtus with dst_path instead using it directly. Agreed. However, the we don't have enough dst's in the bundle as it is because each policy only has one bundle, but there may be aa arbitrary number of different paths and hence different PMTUs over that bundle. >> Now the problem with all this is that it looks pretty complicated. > > I am afraid I still did not understand your troubles completely. > > Actually, the last time when we discussed this we had only one > but _damn_ ugly problem. We have to remember original packet content > to reply with ICMP correctly, when encapsulating. Is it possible > that you are confused with this? We do send invalid ICMP_FRAG_NEEDED > from ip_fragment. PMTU discovery will work only if we reply to original, > not transofrmed packet. See? Well Alexey that's a totally different topic altogether :) Yes this is something that we should look at since it is specified in RFC2401. However, let's get the simple stuff to work first, that is, let's make sure that Linux itself knows what the MTU is before we attempt to send ICMP packets back to the original host. Let me restate my problem in terms of examples. Scenario 1: This is what prompted me to look at this two months ago. The stack assumes that the MTU for an xfrm dst is equal to dst_pmtu(dst) - dst->header_len - dst->trailer_len But this is not true for ESP due to block padding. The trailer_len is variable and the one we store in trailer_len is not the maximum. There are two approaches to this problem. We can either store the maximum trailer_len, or make dst_pmtu(dst) return the correct MTU directly. The former is simple to do, but has the disadvantage of wasting bandwidth up to a block. The latter looks non-trivial, but is pretty simple once we solve the following problems. Scenario 2: Suppose that we have a remote subnet where PMTU doesn't work for whatever reason. However, we do know what the correct MTU is. If IPsec weren't involved, you could simply do ip r r 192.168.0.0/16 dev vpn mtu 1400 But this doesn't work with IPsec as the MTU is retrieved from the path by dst_pmtu. And the path is always the final gateway in the bundle. Scenario 3: Suppose that your default gateway requires you to talk to it using IPsec (wireless gateway for example). As it is, this break PMTU for everything over it. The reason is that when we receive an ICMP packet for a remote host behind the gateway, the MTU will be stored in the route entry as usual. But the route entry is not used to calculate the MTU 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 jt@bougret.hpl.hp.com Wed Jun 16 16:48:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 16:48:05 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GNlqgi003491 for ; Wed, 16 Jun 2004 16:47:52 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 351F1400504; Wed, 16 Jun 2004 16:11:13 -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 QAA11055; Wed, 16 Jun 2004 16:12:40 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BajYn-00089o-00; Wed, 16 Jun 2004 16:11:13 -0700 Date: Wed, 16 Jun 2004 16:11:13 -0700 To: Jeff Garzik Cc: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040616231113.GA31351@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D0D265.3070804@pobox.com> 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: 6028 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: 647 Lines: 15 On Wed, Jun 16, 2004 at 07:06:13PM -0400, Jeff Garzik wrote: > Jean Tourrilhes wrote: > > I think you did not understood my idea at all. > > If you build a set of generic wrappers and hook them in the > >iw_handler table, you could trivially add the features you feel are > >missing into those wrappers. Those wrappers would expose whatever API > >you choose to the driver, call your struct wireless_ops for example. > > That doesn't help anything. Wrappers add code, while not solving the > following problems... You need to start somewhere. This allow you to experiment with the API simply until you get it to the point you like it. Jean From khc@pm.waw.pl Wed Jun 16 17:30:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 17:30:28 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H0U3gi004806 for ; Wed, 16 Jun 2004 17:30:04 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 83F29366; Thu, 17 Jun 2004 01:55:52 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 69B10302D4; Thu, 17 Jun 2004 00:49:59 +0200 (CEST) To: "Eble, Dan" Cc: "'netdev@oss.sgi.com'" Subject: Re: RFC: Cisco HDLC bridging References: From: Krzysztof Halasa Date: Thu, 17 Jun 2004 00:49:59 +0200 In-Reply-To: (Dan Eble's message of "Wed, 16 Jun 2004 08:58:35 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6029 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 Content-Length: 635 Lines: 20 "Eble, Dan" writes: > Ah, yes. But if the device does not have ARPHRD_ETHER the bridge driver > will not allow it to be used as a port. Correct. And while we can "fix" the bridge and other things, it's still not enough. > This is the sethdlc syntax I have chosen to create and destroy the hdlcXeth0 > device: > > sethdlc hdlc0 cisco proto [ enable | disable ] > > Where is 0x6558 for bridged ethernet packets (or maybe "ether", but I > have not put that in yet). I figure this will be useful to enable and > disable other protocols too. Ok. I'd prefer "ether", though. -- Krzysztof Halasa, B*FH From garzik@havoc.gtf.org Wed Jun 16 18:02:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 18:02:08 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H123gi006197 for ; Wed, 16 Jun 2004 18:02:03 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 98D8E7663 for ; Wed, 16 Jun 2004 21:01:57 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5H11vO6009781 for netdev@oss.sgi.com; Wed, 16 Jun 2004 21:01:57 -0400 Date: Wed, 16 Jun 2004 21:01:57 -0400 From: Jeff Garzik To: NetDev list Subject: [BK PATCHES] 2.6.x net driver updates Message-ID: <20040617010157.GA9769@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: 6030 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: 6195 Lines: 150 (just sent to andrew/linus) BK users may do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: Documentation/networking/00-INDEX | 2 drivers/net/3c501.c | 2 drivers/net/3c503.c | 6 drivers/net/3c505.c | 3 drivers/net/3c507.c | 4 drivers/net/3c523.c | 4 drivers/net/3c527.c | 4 drivers/net/8139too.c | 2 drivers/net/82596.c | 4 drivers/net/Kconfig | 85 drivers/net/Makefile | 1 drivers/net/ac3200.c | 8 drivers/net/acenic.c | 248 - drivers/net/acenic.h | 1 drivers/net/apne.c | 6 drivers/net/arm/Kconfig | 17 drivers/net/arm/Makefile | 1 drivers/net/arm/smc91x.c | 2171 +++++++++++++++++ drivers/net/arm/smc91x.h | 829 ++++++ drivers/net/at1700.c | 8 drivers/net/cs89x0.c | 8 drivers/net/defxx.c | 6 drivers/net/e2100.c | 6 drivers/net/eepro.c | 6 drivers/net/eexpress.c | 2 drivers/net/epic100.c | 5 drivers/net/es3210.c | 2 drivers/net/eth16i.c | 10 drivers/net/ewrk3.c | 6 drivers/net/fealnx.c | 5 drivers/net/fmv18x.c | 6 drivers/net/forcedeth.c | 3 drivers/net/hp-plus.c | 6 drivers/net/hp.c | 10 drivers/net/hp100.c | 2 drivers/net/ibmlana.c | 6 drivers/net/isa-skeleton.c | 2 drivers/net/jazzsonic.c | 4 drivers/net/lance.c | 2 drivers/net/lne390.c | 10 drivers/net/lp486e.c | 4 drivers/net/natsemi.c | 7 drivers/net/ne-h8300.c | 6 drivers/net/ne.c | 6 drivers/net/ne2.c | 8 drivers/net/ne2k_cbus.c | 6 drivers/net/ne3210.c | 10 drivers/net/ni52.c | 4 drivers/net/ns83820.c | 4 drivers/net/oaknet.c | 2 drivers/net/r8169.c | 2 drivers/net/smc-mca.c | 4 drivers/net/smc-ultra.c | 6 drivers/net/smc-ultra32.c | 4 drivers/net/smc9194.c | 8 drivers/net/starfire.c | 2 drivers/net/stnic.c | 4 drivers/net/sun3_82586.c | 4 drivers/net/sungem.c | 2 drivers/net/sunhme.c | 4 drivers/net/tulip/Kconfig | 15 drivers/net/tulip/winbond-840.c | 6 drivers/net/via-rhine.c | 306 +- drivers/net/via-velocity.c | 3277 ++++++++++++++++++++++++++ drivers/net/via-velocity.h | 1885 ++++++++++++++ drivers/net/wd.c | 6 drivers/net/wireless/prism54/isl_38xx.c | 134 - drivers/net/wireless/prism54/isl_38xx.h | 10 drivers/net/wireless/prism54/isl_ioctl.c | 196 - drivers/net/wireless/prism54/isl_ioctl.h | 1 drivers/net/wireless/prism54/islpci_dev.c | 161 + drivers/net/wireless/prism54/islpci_dev.h | 22 drivers/net/wireless/prism54/islpci_eth.c | 73 drivers/net/wireless/prism54/islpci_hotplug.c | 3 drivers/net/wireless/prism54/islpci_mgt.c | 165 - drivers/net/wireless/prism54/islpci_mgt.h | 11 drivers/net/wireless/prism54/oid_mgt.c | 88 drivers/net/wireless/prism54/oid_mgt.h | 2 drivers/net/wireless/prism54/prismcompat.h | 46 drivers/net/yellowfin.c | 7 drivers/net/zorro8390.c | 6 81 files changed, 9142 insertions(+), 888 deletions(-) through these ChangeSets: D (Alex): o fealnx-mac-address-and-other-issues.patch Adrian Bunk: o add NAPI help texts Alan Cox: o add new via-velocity gigabit ethernet driver Andrew Morton: o prism94 build fix Arthur Othieno: o Kill stale references to Documentation/networking/8139too.txt Evgeniy Polyakov: o Typo in ethtool code in acenic driver Herbert Xu: o [NETDRV #2] Use driver-specific name for resources o [NETDRV #1] Ifdef builtin-only probe in ISA/MCA drivers Jeff Garzik: o [netdrvr acenic] remove unneeded ifdefs Margit Schubert-While: o prism54: White space and indentation o prism54: Fix typo o prism54: Fix channel stats, bump version to 1.2 o prism54: Reduce module verbosity o prism54: Align skb patch o prism54: Add likely/unlikely, KO wds completely o prism54: Don't allow mib reads while unconfigured o prism54: Fix bug 77, strengthened oid txn o prism54: Fix bugs 39/73 o prism54: Fix bugs 74/75 o prism54: Fix endian patch o prism54: Kernel compatibility Roger Luethi: o Add rhine_power_init(): get power regs into sane state o Rewrite special-casing o Return codes for rhine_init_one o Nuke all pci_flags o Nuke default_port, references to if_port, medialock o Nuke HasESIPhy and related code o Nuke CanHaveMII and related code o Nuke HAS_IP_COPYSUM o Nuke HAS_IP_COPYSUM for net drivers Russell King: o add ARM smc91x driver Stephen Hemminger: o fix oops from acenic ethtool From mcgrof@studorgs.rutgers.edu Wed Jun 16 23:34:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 23:34:13 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H6Y0gi020773 for ; Wed, 16 Jun 2004 23:34:00 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 4FA3DF9D9A; Thu, 17 Jun 2004 01:57:51 -0400 (EDT) Date: Thu, 17 Jun 2004 01:57:51 -0400 To: Scott Feldman Cc: Gerald Britton , Gertjan van Wingerde , netdev@oss.sgi.com Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617055751.GH6253@ruslug.rutgers.edu> Mail-Followup-To: Scott Feldman , Gerald Britton , Gertjan van Wingerde , netdev@oss.sgi.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <20040616152808.GA6270@fog.sekrit.org> <1087408417.25912.79.camel@sfeldma-mobl2.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1087408417.25912.79.camel@sfeldma-mobl2.dsl-verizon.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: 6032 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: 346 Lines: 10 On Wed, Jun 16, 2004 at 10:53:38AM -0700, Scott Feldman wrote: > There are some drivers (i.e. prism54) that use module params that are > duplicates of the standard settings. These need cleaning up as well. I've removed those already in my current WPA work. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From kala@pinerecords.com Wed Jun 16 23:56:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Jun 2004 23:56:20 -0700 (PDT) Received: from louise.pinerecords.com (louise.pinerecords.com [213.168.176.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H6uCgi022460 for ; Wed, 16 Jun 2004 23:56:14 -0700 Received: from louise.pinerecords.com (localhost [127.0.0.1]) by louise.pinerecords.com with ESMTP id i5H6u7Nb012035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2004 08:56:08 +0200 Received: (from kala@localhost) by louise.pinerecords.com (submit) id i5H6u7VR012034; Thu, 17 Jun 2004 08:56:07 +0200 Date: Thu, 17 Jun 2004 08:56:07 +0200 From: Tomas Szepe To: viro@parcelfarce.linux.theplanet.co.uk Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Linux 2.6.7 Message-ID: <20040617065607.GA11999@louise.pinerecords.com> References: <20040616111329.GA1571@louise.pinerecords.com> <20040616121850.GO12308@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616121850.GO12308@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.4.2.1i X-archive-position: 6033 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szepe@pinerecords.com Precedence: bulk X-list: netdev Content-Length: 724 Lines: 21 On Jun-16 2004, Wed, 13:18 +0100 viro@parcelfarce.linux.theplanet.co.uk wrote: > > 2.6.7's airo.ko (unlike 2.6.6's) won't allow the user to set > > ESSID via "echo myessid >/proc/driver/aironet/ethX/SSID". > > > > Changes like this shouldn't probably be made in the middle > > of a stable series. > > Changes like this are called bugs. The thing is, original variant of > function (actually, both read and write) was also buggy and trivially > exploitable, so fixing it was needed. Fscking it up was not, obviously. Sure, I just assumed somebody had done this on purpose. > Fix follows; see if it works for you. Works for me, thanks. -- Tomas Szepe From herbert@gondor.apana.org.au Thu Jun 17 01:18:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 01:18:43 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H8IXgi031086 for ; Thu, 17 Jun 2004 01:18: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 1Bas5Y-0004Hi-00; Thu, 17 Jun 2004 18:17:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bas5K-0002EX-00; Thu, 17 Jun 2004 18:17:22 +1000 Date: Thu, 17 Jun 2004 18:17:22 +1000 To: "David S. Miller" Cc: Alexey Kuznetsov , schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040617081722.GA8559@gondor.apana.org.au> References: <20040613183622.3a814506.davem@redhat.com> <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616134711.499209c9.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6034 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: 972 Lines: 29 On Wed, Jun 16, 2004 at 01:47:11PM -0700, David S. Miller wrote: > On Thu, 17 Jun 2004 00:37:48 +0400 > Alexey Kuznetsov wrote: > > > Sort of. I think it should happen after killing reference to dst->dev: > ... > > but before dropping reference to dev: > ... > > So, I think it should look like: > > > > dst->dev = &loopback_dev; > > dev_hold(&loopback_dev); > > + synchronize_kernel(); > > dev_put(dev); > > Perfect, that's what I put into my tree then, plus some comment. Yes we definitely want this call. But wouldn't it be better to do one call at the top level, say at the end of netdev_wait_allrefs? Otherwise we may end up with lots of synchronize_kernel() calls scattered in each individual event handler. 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 Jun 17 01:34:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 01:34:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H8Xvgi031960 for ; Thu, 17 Jun 2004 01:33: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 1BasKa-0004O3-00; Thu, 17 Jun 2004 18:33:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BasKW-0002IK-00; Thu, 17 Jun 2004 18:33:04 +1000 Date: Thu, 17 Jun 2004 18:33:03 +1000 To: "David S. Miller" Cc: Alexey Kuznetsov , schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040617083303.GA8810@gondor.apana.org.au> References: <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20040617081722.GA8559@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6035 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: 1697 Lines: 59 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 17, 2004 at 06:17:22PM +1000, herbert wrote: > > Yes we definitely want this call. But wouldn't it be better to do one > call at the top level, say at the end of netdev_wait_allrefs? Something like should be good enough. 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 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/core/dev.c 1.145 vs edited ===== --- 1.145/net/core/dev.c 2004-06-04 15:02:47 +10:00 +++ edited/net/core/dev.c 2004-06-17 18:31:12 +10:00 @@ -3033,6 +3033,12 @@ netdev_wait_allrefs(dev); + /* Wait for at least one quiescent state before + * destroying dev. This ensures users like + * dst->dev are completely finished. + */ + synchronize_net(); + /* paranoia */ BUG_ON(atomic_read(&dev->refcnt)); BUG_TRAP(!dev->ip_ptr); ===== net/core/dst.c 1.19 vs edited ===== --- 1.19/net/core/dst.c 2004-06-17 06:42:22 +10:00 +++ edited/net/core/dst.c 2004-06-17 18:31:46 +10:00 @@ -231,12 +231,6 @@ if (unregister) { dst->dev = &loopback_dev; dev_hold(&loopback_dev); - - /* Wait for at least one quiescent state after - * detaching the stale device from dst. - */ - synchronize_kernel(); - dev_put(dev); if (dst->neighbour && dst->neighbour->dev == dev) { dst->neighbour->dev = &loopback_dev; --fUYQa+Pmc3FrFX/N-- From arekm@pld-linux.org Thu Jun 17 01:54:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 01:54:40 -0700 (PDT) Received: from smtp.sys.beep.pl (exim@smtp.sys.beep.pl [195.245.198.13]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H8sZgi003357 for ; Thu, 17 Jun 2004 01:54:36 -0700 Received: from [156.17.236.105] (helo=[192.168.2.2] ident=arekm-m1) by maja.beep.pl with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BajU3-0006d6-Ty for netdev@oss.sgi.com; Thu, 17 Jun 2004 01:06:23 +0200 From: Arkadiusz Miskiewicz Organization: SelfOrganizing To: netdev@oss.sgi.com Subject: 3c59x.c NAPI Date: Thu, 17 Jun 2004 01:06:39 +0200 User-Agent: KMail/1.6.52 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-2" Message-Id: <200406170106.39586.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 i5H8sZgi003357 X-archive-position: 6036 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: 389 Lines: 13 Hi, Is anyone working on converting 3c59x.c driver to NAPI? It seems that there was patch for 2.6 doing that conversion but it has not been merged http://www.spinics.net/lists/linux-net/msg08757.html (probably because it doesn't look good). -- Arkadiusz Mikiewicz CS at FoE, Wroclaw University of Technology arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux From geert@linux-m68k.org Thu Jun 17 03:06:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 03:06:27 -0700 (PDT) Received: from witte.sonytel.be (witte.sonytel.be [80.88.33.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HA6Lgi008441 for ; Thu, 17 Jun 2004 03:06:22 -0700 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5HA6HXK009963; Thu, 17 Jun 2004 12:06:17 +0200 (MEST) Date: Thu, 17 Jun 2004 12:06:17 +0200 (MEST) From: Geert Uytterhoeven To: Marcelo Tosatti , "David S. Miller" cc: Linux Kernel Development , netdev@oss.sgi.com Subject: ip6_tables warning (was: Re: Linux 2.4.27-pre6) In-Reply-To: <20040616183343.GA9940@logos.cnet> Message-ID: References: <20040616183343.GA9940@logos.cnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6037 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: netdev Content-Length: 611 Lines: 19 This is not a new problem, but I never bothered to report it before: | ip6_tables.c: In function `tcp_match': | ip6_tables.c:1596: warning: implicit declaration of function `ipv6_skip_exthdr' It needs to include to kill the warning. Sorry, no patch, since my development machine is offline. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From yoshfuji@linux-ipv6.org Thu Jun 17 03:13:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 03:13:04 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HACxgi009098 for ; Thu, 17 Jun 2004 03:12:59 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A15E233CE5; Thu, 17 Jun 2004 19:13:56 +0900 (JST) Date: Thu, 17 Jun 2004 19:13:56 +0900 (JST) Message-Id: <20040617.191356.62693754.yoshfuji@linux-ipv6.org> To: geert@linux-m68k.org, davem@redhat.com Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: ip6_tables warning From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040616183343.GA9940@logos.cnet> 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: 6038 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: 949 Lines: 25 In article (at Thu, 17 Jun 2004 12:06:17 +0200 (MEST)), Geert Uytterhoeven says: > This is not a new problem, but I never bothered to report it before: > > | ip6_tables.c: In function `tcp_match': > | ip6_tables.c:1596: warning: implicit declaration of function `ipv6_skip_exthdr' > It needs to include to kill the warning. Here it is. ===== net/ipv6/netfilter/ip6_tables.c 1.17 vs edited ===== --- 1.17/net/ipv6/netfilter/ip6_tables.c 2004-06-07 12:13:18 +09:00 +++ edited/net/ipv6/netfilter/ip6_tables.c 2004-06-17 19:11:08 +09:00 @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pragatidhingra@yahoo.com Thu Jun 17 07:16:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 07:16:39 -0700 (PDT) Received: from web90108.mail.scd.yahoo.com (web90108.mail.scd.yahoo.com [66.218.94.79]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HEGVgi024098 for ; Thu, 17 Jun 2004 07:16:33 -0700 Message-ID: <20040617141626.60307.qmail@web90108.mail.scd.yahoo.com> Received: from [203.200.200.162] by web90108.mail.scd.yahoo.com via HTTP; Thu, 17 Jun 2004 07:16:26 PDT Date: Thu, 17 Jun 2004 07:16:26 -0700 (PDT) From: Pragati Dhingra Subject: CONFIG_NET_FASTROUTE in 8390 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-935360949-1087481786=:58766" X-archive-position: 6041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pragatidhingra@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2496 Lines: 57 --0-935360949-1087481786=:58766 Content-Type: text/plain; charset=us-ascii Hi, I was browsing through the fast routing code for 8390 (the link to which I got from kernel configuration help file) In e8390_fast_route function, struct rtable *rt; and for indriver lookup, if (rt == NULL || ((u16*)&iph->daddr)[0] != ((u16*)&rt->key.dst)[0] || ((u16*)&iph->daddr)[1] != ((u16*)&rt->key.dst)[1] || ((u16*)&iph->saddr)[0] != ((u16*)&rt->key.src)[0] || ((u16*)&iph->saddr)[1] != ((u16*)&rt->key.src)[1] || rt->u.dst.obsolete) struct rtable does not have a member named key and I could not locate a #define which would define "key". Can you pls tell me what is key refering to and how? (ofcourse it needs to refer to destination address in route table entry, but how is what is really puzzling me) Thanks and regards, Pragati --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! --0-935360949-1087481786=:58766 Content-Type: text/html; charset=us-ascii
Hi,
 
I was browsing through the fast routing code for 8390 (the link to which I got from kernel configuration help file)
 
In e8390_fast_route function,
 
struct rtable *rt;
 
and for indriver lookup,
 
 if (rt == NULL ||
     ((u16*)&iph->daddr)[0] != ((u16*)&rt->key.dst)[0] ||
     ((u16*)&iph->daddr)[1] != ((u16*)&rt->key.dst)[1] ||
     ((u16*)&iph->saddr)[0] != ((u16*)&rt->key.src)[0] ||
     ((u16*)&iph->saddr)[1] != ((u16*)&rt->key.src)[1] ||
     rt->u.dst.obsolete)
 
struct rtable does not have a member named key and I could not locate a #define which would define "key".
 
Can you pls tell me what is key refering to and how? (ofcourse it needs to refer to destination address in route table entry, but how is what is really puzzling me)
 
Thanks and regards,
Pragati

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage! --0-935360949-1087481786=:58766-- From ams@wiw.org Thu Jun 17 08:19:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 08:19:49 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HFJcgi002298 for ; Thu, 17 Jun 2004 08:19:38 -0700 Received: from lustre.dyn.wiw.org (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 3DB4E1BDE7C; Thu, 17 Jun 2004 17:19:33 +0200 (CEST) Received: from ams by lustre.dyn.wiw.org with local (Exim 4.20) id 1Bayfl-0002E0-0s; Thu, 17 Jun 2004 20:49:25 +0530 Date: Thu, 17 Jun 2004 20:49:24 +0530 From: Abhijit Menon-Sen To: Pragati Dhingra Cc: netdev@oss.sgi.com Subject: Re: CONFIG_NET_FASTROUTE in 8390 Message-ID: <20040617204924.H5207@lustre.dyn.wiw.org> References: <20040617141626.60307.qmail@web90108.mail.scd.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617141626.60307.qmail@web90108.mail.scd.yahoo.com> X-archive-position: 6042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ams@wiw.org Precedence: bulk X-list: netdev Content-Length: 469 Lines: 13 At 2004-06-17 07:16:26 -0700, pragatidhingra@yahoo.com wrote: > > struct rtable does not have a member named key and I could not locate > a #define which would define "key". In 2.4 kernels, rtable does have a "struct rt_key" member named key, and the code you're reading (I couldn't find the e8390_fast_route function) is probably for 2.4. In 2.6 kernel, the rt_key has been replaced by a "struct flowi *". (See include/net/route.h and ip_route_output_key.) -- ams From kaber@trash.net Thu Jun 17 09:01:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 09:02:01 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HG1vgi011633 for ; Thu, 17 Jun 2004 09:01:58 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BazLr-0003yt-00; Thu, 17 Jun 2004 18:02:55 +0200 Message-ID: <40D1C088.4090307@trash.net> Date: Thu, 17 Jun 2004 18:02:16 +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: Tobias DiPasquale CC: netdev , linux-net , netfilter Subject: Re: deleting a conntrack record References: <876ef97a0406170807663b89e0@mail.gmail.com> In-Reply-To: <876ef97a0406170807663b89e0@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6044 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: 3084 Lines: 86 Tobias DiPasquale wrote: > Hello all, > > I have a module that exports a /proc entry which takes a string with 4 > args in it (src IP/port and dst IP/port) and then attempts to delete > the conntrack entry for the TCP connection associated with those > arguments. Here's the code in question (keep reading past the code for > a description of the problem I'm having): > > > static inline int kill_ct_record( const struct ip_conntrack *c, void *p) > { > struct ip_conntrack *q = (struct ip_conntrack *)p; > > if (!memcmp( &c->tuplehash[IP_CT_DIR_ORIGINAL], > &q->tuplehash[IP_CT_DIR_ORIGINAL], > sizeof( struct ip_conntrack_tuple_hash))) { > ip_conntrack_put( q); > return 1; > } > return 0; > } > > static int delete_ct_record( u_int32_t src, u_int16_t sport, u_int32_t > dst, u_int16_t dport) > { > struct ip_conntrack_tuple tuple; > struct ip_conntrack_tuple_hash *h; > > memset( &tuple, 0, sizeof( tuple)); > tuple.src.ip = src; > tuple.src.u.tcp.port = sport; > tuple.dst.ip = dst; > tuple.dst.u.tcp.port = dport; > tuple.dst.protonum = IPPROTO_TCP; > h = ip_conntrack_find_get( &tuple, NULL); > if (!h) > return -ENOENT; > ip_ct_selective_cleanup( kill_ct_record, h->ctrack); > return 1; > } > > > The problem is as follows: > > There is a userspace script that runs from cron every 5 minutes. It > looks through the /proc/net/ip_conntrack listing to see if any > connections are "stale" (i.e. haven't seen a packet from them in > some amount of time). It then feeds their connection information > into my module's /proc entry so that those conntrack records can > be destroyed. Why don't you just adjust the timeout values in /proc/sys/net/ipv4/netfilter ? > > In the kill_ct_record() function in the module, if the > ip_conntrack_put() call is not commented out, this causes the box > to go into some infinite loop after some unspecified amount of time. > There is no LKCD dump and I don't know what happened since I wasn't > physically present for the crash in any of the instances. > > On the other hand, when the ip_conntrack_put() call _is_ commented > out, the system leaks memory from conntrack as indicated in the > ip_conntrack line in /proc/slabinfo. But the crash doesn't happen > under that condition. The function passed to ip_ct_selective_cleanup is supposed to decide if a conntrack should be destroyed by returning 0/1, not to do it itself. ip_ct_selective_cleanup tries to destroy the already destroyed conntrack. > > So, is there a cleaner way to hand-delete a conntrack record? Or is > this the only method? Or is there some error in the way that I am > doing the above? > > By the way, this is almost exactly what ctnetlink does to delete a > conntrack record so any errors discovered here will almost surely have > to be fixed there, as well. > Thanks for pointing that out, I've fixed the ctnetlink code. Regards Patrick From kaber@trash.net Thu Jun 17 09:42:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 09:42:19 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HGgDgi014973 for ; Thu, 17 Jun 2004 09:42:14 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bazyr-0004Z6-00; Thu, 17 Jun 2004 18:43:13 +0200 Message-ID: <40D1C9FB.1070802@trash.net> Date: Thu, 17 Jun 2004 18:42:35 +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: Tobias DiPasquale CC: netdev , linux-net , netfilter Subject: Re: deleting a conntrack record References: <876ef97a0406170807663b89e0@mail.gmail.com> <40D1C088.4090307@trash.net> <876ef97a04061709173c8f1a09@mail.gmail.com> In-Reply-To: <876ef97a04061709173c8f1a09@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6046 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: 1345 Lines: 29 Tobias DiPasquale wrote: > On Thu, 17 Jun 2004 18:02:16 +0200, Patrick McHardy wrote: > >>The function passed to ip_ct_selective_cleanup is supposed to decide >>if a conntrack should be destroyed by returning 0/1, not to do it >>itself. ip_ct_selective_cleanup tries to destroy the already destroyed >>conntrack. > > This results in a memory leak in the conntrack slab cache. If you > don't call ip_conntrack_put(), the conntrack entry leaves the > ip_ct_selective_cleanup() function with a value >0 and thus is a > permanent part of the scenery in RAM. As well, its been removed from > the conntrack hash table, so it no longer appears in > /proc/net/ip_conntrack, but you can see the effects by viewing > /proc/slabinfo. Now I remember - the reason why ctnetlink called ip_conntrack_put in ctnetlink_kill is because it uses ip_conntrack_find_get before, which increments the reference count. This is wrong because the conntrack is then destroyed immediately after returning 1 to ip_ct_selective_cleanup, but still used for comparing the tuple. You (and ctnetlink) need to call ip_conntrack_put after the call to ip_ct_selective_cleanup. In fact you shouldn't use ip_ct_selective_cleanup at all but destroy it yourself. You already have a reference, so there is no need to iterate through the entire hash. Regards Patrick From davem@redhat.com Thu Jun 17 10:10:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 10:10:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HHApgi016108 for ; Thu, 17 Jun 2004 10:10: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 i5HHAbe1010950; Thu, 17 Jun 2004 13:10:37 -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 i5HHAb031931; Thu, 17 Jun 2004 13:10:37 -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 i5HHAGj3021240; Thu, 17 Jun 2004 13:10:19 -0400 Date: Thu, 17 Jun 2004 10:10:16 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040617101016.44512cb1.davem@redhat.com> In-Reply-To: <20040617083303.GA8810@gondor.apana.org.au> References: <20040614015013.GA11048@gondor.apana.org.au> <20040613210725.70dbd016.davem@redhat.com> <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> <20040617083303.GA8810@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6047 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: 420 Lines: 12 Herbert, you still don't understand what the synchronize_kernel() is for. It is to make sure that anyone (other cpus using the dst) who "saw" the old dst->dev is done doing whatever they were doing _BEFORE_ we put the device reference. The best we could do is accumulate devices to be put onto some kind of list, then at the end of dst_ifdown() do one synchronize_kernel() then walk the list putting all the devices. From davem@redhat.com Thu Jun 17 10:12:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 10:12:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HHCVgi016434 for ; Thu, 17 Jun 2004 10:12: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 i5HHCOe1011455; Thu, 17 Jun 2004 13:12: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 i5HHCO032531; Thu, 17 Jun 2004 13:12:24 -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 i5HHC5t1022037; Thu, 17 Jun 2004 13:12:06 -0400 Date: Thu, 17 Jun 2004 10:12:05 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: geert@linux-m68k.org, marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: ip6_tables warning Message-Id: <20040617101205.06ec7a0c.davem@redhat.com> In-Reply-To: <20040617.191356.62693754.yoshfuji@linux-ipv6.org> References: <20040616183343.GA9940@logos.cnet> <20040617.191356.62693754.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6048 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: 79 Lines: 4 Applied, thanks Yoshfuji. I've seen this too, just was too lazy to fix it :) From kuznet@ms2.inr.ac.ru Thu Jun 17 10:27:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 10:27:07 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HHR2gi017293 for ; Thu, 17 Jun 2004 10:27:05 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id VAA10354; Thu, 17 Jun 2004 21:24:49 +0400 Date: Thu, 17 Jun 2004 21:24:49 +0400 From: Alexey Kuznetsov To: "David S. Miller" Cc: Herbert Xu , schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040617172449.GA10303@ms2.inr.ac.ru> References: <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> <20040617083303.GA8810@gondor.apana.org.au> <20040617101016.44512cb1.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617101016.44512cb1.davem@redhat.com> User-Agent: Mutt/1.5.6i X-archive-position: 6050 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 506 Lines: 14 Hello! > It is to make sure that anyone (other cpus using the dst) who "saw" > the old dst->dev is done doing whatever they were doing _BEFORE_ > we put the device reference. Actually, he noticed right thing. I forgot that this function works in context when dev, which is argument is of the function, is held, so dev_put() here can be safely replaced with __dev_put(). So, synchonize_kernel() can be moved somewhere to unregister_netdevice(), (maybe, it is already present there under surface) Alexey From shemminger@osdl.org Thu Jun 17 10:26:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 10:26:37 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HHQYgi017104 for ; Thu, 17 Jun 2004 10:26:34 -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 i5HHQMr10199; Thu, 17 Jun 2004 10:26:22 -0700 Date: Thu, 17 Jun 2004 10:26:22 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] add annotation to sock_filter.h Message-Id: <20040617102622.5f07fc56@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: 6049 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: 699 Lines: 25 Since sock_fprog is argument in ioctl, the filter pointer needs to be annotated. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/filter.h b/include/linux/filter.h --- a/include/linux/filter.h 2004-06-16 15:26:32 -07:00 +++ b/include/linux/filter.h 2004-06-16 15:26:32 -07:00 @@ -5,6 +5,8 @@ #ifndef __LINUX_FILTER_H__ #define __LINUX_FILTER_H__ +#include + /* * Current version of the filter code architecture. */ @@ -27,7 +29,7 @@ struct sock_fprog /* Required for SO_ATTACH_FILTER. */ { unsigned short len; /* Number of filter blocks */ - struct sock_filter *filter; + struct sock_filter __user *filter; }; #ifdef __KERNEL__ From davem@redhat.com Thu Jun 17 10:53:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 10:53:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HHrvgi019001 for ; Thu, 17 Jun 2004 10:53:57 -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 i5HHrhe1022546; Thu, 17 Jun 2004 13:53:43 -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 i5HHrh014036; Thu, 17 Jun 2004 13:53:43 -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 i5HHrPjM012616; Thu, 17 Jun 2004 13:53:25 -0400 Date: Thu, 17 Jun 2004 10:53:24 -0700 From: "David S. Miller" To: Alexey Kuznetsov Cc: herbert@gondor.apana.org.au, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040617105324.554c631b.davem@redhat.com> In-Reply-To: <20040617172449.GA10303@ms2.inr.ac.ru> References: <20040614042216.GA28669@gondor.apana.org.au> <20040614102858.GA12343@gondor.apana.org.au> <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> <20040617083303.GA8810@gondor.apana.org.au> <20040617101016.44512cb1.davem@redhat.com> <20040617172449.GA10303@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6051 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: 638 Lines: 13 On Thu, 17 Jun 2004 21:24:49 +0400 Alexey Kuznetsov wrote: > Actually, he noticed right thing. I forgot that this function > works in context when dev, which is argument is of the function, > is held, so dev_put() here can be safely replaced with __dev_put(). > > So, synchonize_kernel() can be moved somewhere to unregister_netdevice(), > (maybe, it is already present there under surface) It occurs, via synchronize_net(), but this happens before NETDEV_UNREGISTER event is sent out. Is it sufficient? I think not, and that we need to add another call in unregister_netdevice() right before final dev_put(). From davem@redhat.com Thu Jun 17 10:59:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 10:59:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HHxDgi019460 for ; Thu, 17 Jun 2004 10:59:14 -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 i5HHx3e1024315; Thu, 17 Jun 2004 13:59: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 i5HHx3016193; Thu, 17 Jun 2004 13:59:03 -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 i5HHwiEG015887; Thu, 17 Jun 2004 13:58:45 -0400 Date: Thu, 17 Jun 2004 10:58:43 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, herbert@gondor.apana.org.au, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-Id: <20040617105843.314dfe30.davem@redhat.com> In-Reply-To: References: <20040616202341.GD29781@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6052 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: 892 Lines: 21 On Thu, 17 Jun 2004 09:11:50 +1000 Herbert Xu wrote: > This is what prompted me to look at this two months ago. The stack > assumes that the MTU for an xfrm dst is equal to > > dst_pmtu(dst) - dst->header_len - dst->trailer_len > > But this is not true for ESP due to block padding. The trailer_len > is variable and the one we store in trailer_len is not the maximum. > > There are two approaches to this problem. We can either store the > maximum trailer_len, or make dst_pmtu(dst) return the correct MTU > directly. > > The former is simple to do, but has the disadvantage of wasting > bandwidth up to a block. The latter looks non-trivial, but is > pretty simple once we solve the following problems. Do you see what xfrm_get_mss() does? It calls into x->type->get_max_size() and this is where ESP reports this kind of thing (re: block padding). From davem@redhat.com Thu Jun 17 11:00:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:00:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HI0lgi019790 for ; Thu, 17 Jun 2004 11:00:49 -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 i5HI0je1024847; Thu, 17 Jun 2004 14:00:45 -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 i5HI0i016842; Thu, 17 Jun 2004 14:00:44 -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 i5HI0RZF017183; Thu, 17 Jun 2004 14:00:27 -0400 Date: Thu, 17 Jun 2004 11:00:26 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] add annotation to sock_filter.h Message-Id: <20040617110026.1b92556f.davem@redhat.com> In-Reply-To: <20040617102622.5f07fc56@dell_ss3.pdx.osdl.net> References: <20040617102622.5f07fc56@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6053 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: 252 Lines: 8 On Thu, 17 Jun 2004 10:26:22 -0700 Stephen Hemminger wrote: > Since sock_fprog is argument in ioctl, the filter pointer needs to be annotated. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From codeslinger@gmail.com Thu Jun 17 11:04:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:04:28 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HI4Ogi020192 for ; Thu, 17 Jun 2004 11:04:24 -0700 Received: by mproxy.gmail.com with SMTP id v30so57360rnb for ; Thu, 17 Jun 2004 11:04:19 -0700 (PDT) Received: by 10.38.97.42 with SMTP id u42mr143318rnb; Thu, 17 Jun 2004 09:17:39 -0700 (PDT) Message-ID: <876ef97a04061709173c8f1a09@mail.gmail.com> Date: Thu, 17 Jun 2004 12:17:39 -0400 From: Tobias DiPasquale To: netdev , linux-net , netfilter Subject: Re: deleting a conntrack record In-Reply-To: <40D1C088.4090307@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <876ef97a0406170807663b89e0@mail.gmail.com> <40D1C088.4090307@trash.net> X-archive-position: 6054 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: codeslinger@gmail.com Precedence: bulk X-list: netdev Content-Length: 1371 Lines: 31 On Thu, 17 Jun 2004 18:02:16 +0200, Patrick McHardy wrote: > Why don't you just adjust the timeout values in > /proc/sys/net/ipv4/netfilter ? Can't, because I only want to shorten the lifespans of some particular TCP connections and also when I delete a record I need to do some other stuff that's associated with the destruction of that connection. > The function passed to ip_ct_selective_cleanup is supposed to decide > if a conntrack should be destroyed by returning 0/1, not to do it > itself. ip_ct_selective_cleanup tries to destroy the already destroyed > conntrack. This results in a memory leak in the conntrack slab cache. If you don't call ip_conntrack_put(), the conntrack entry leaves the ip_ct_selective_cleanup() function with a value >0 and thus is a permanent part of the scenery in RAM. As well, its been removed from the conntrack hash table, so it no longer appears in /proc/net/ip_conntrack, but you can see the effects by viewing /proc/slabinfo. I have printed the integral value of the ct_general.use variable out in order to confirm this on many occassions. If this is not the case, then something extremely weird is going on with my kernel. (btw, the kernel is a kernel.org 2.4.26 with the clear_fpu and the 2.4.26 LKCD (from the ML) patch applied) -- [ Tobias DiPasquale ] 0x636f6465736c696e67657240676d61696c2e636f6d From jt@bougret.hpl.hp.com Thu Jun 17 11:09:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:09:08 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HI8rgi020796 for ; Thu, 17 Jun 2004 11:08:53 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id B91D41C00313; Thu, 17 Jun 2004 10:47:18 -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 KAA09381; Thu, 17 Jun 2004 10:48:47 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb0yr-00082M-00; Thu, 17 Jun 2004 10:47:17 -0700 Date: Thu, 17 Jun 2004 10:47:17 -0700 To: Jeff Garzik Cc: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617174717.GA30460@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D0D265.3070804@pobox.com> 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: 6055 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: 4001 Lines: 117 On Wed, Jun 16, 2004 at 07:06:13PM -0400, Jeff Garzik wrote: > > It's not Jeff's weird personal preference that iw_handler be killed... > type-opaque interfaces cause real problems. A good C programmer should > very, very rarely use type-casting. Yes, I know that I am really a perverse mind and I did designed the API this way only to make your life miserable and to sabotage the Linux kernel. As a matter of fact, I tried the strongly type approach you advocate and find its kernel overhead not acceptable. Note that people not using wireless have to suffer from this bloat, and wireless extensions are used in embeeded platforms such as OpenAP, iPaq and Zaurus where footprint matters. There was additional benefits, such as the ability to use a single handler for multiple commands (horror !), and I know of a few driver using this feature. Now, it seems that you clearly have not understood my proposal, so I made a little patch, hopping that it will clear the obvious miscommunication. Patch is below. I hope you will notice that the changes are fairly trivial and clean. And it's backward compatible. I also want you to notice that the code is quasi optimal, compared to rewritting the API, there is only one additional function call (plus the backward compatibility). I know you won't believe me, so verify that yourself. I think this is a small price to pay for keeping backward compatibility with all those drivers outside the kernel (see my web page). > Jeff Now, I will have to excuse myself, and let you guys argue over my patch. I have a full time job and a new baby that require my dedicated attention, plus a huge backlog of Linux stuff (WTool release, WPA, RtNetlink stuff, IrDA patches...). I don't have the luxury of having Linux as my primary occupation. Have fun... Jean -------------------------------------------------------- --- linux/include/net/iw_handler.j1.h Thu Jun 17 10:16:22 2004 +++ linux/include/net/iw_handler.h Thu Jun 17 10:17:24 2004 @@ -301,6 +301,9 @@ typedef int (*iw_handler)(struct net_dev */ struct iw_handler_def { + /* Wireless Ops definitions */ + struct wireless_ops * wireless_ops; + /* Number of handlers defined (more precisely, index of the * last defined handler + 1) */ __u16 num_standard; --- linux/net/core/wireless.j1.c Thu Jun 17 10:08:45 2004 +++ linux/net/core/wireless.c Thu Jun 17 10:28:59 2004 @@ -343,8 +343,14 @@ static inline iw_handler get_handler(str if(dev->wireless_handlers == NULL) return NULL; - /* Try as a standard command */ index = cmd - SIOCIWFIRST; + + /* Try as wireless_ops */ + if((index < (SIOCIWFIRSTPRIV - SIOCIWFIRST)) && + (dev->wireless_handlers->wireless_ops != NULL)) + return &iw_process_wireless_ops; + + /* Try as a standard command */ if(index < dev->wireless_handlers->num_standard) return dev->wireless_handlers->standard[index]; @@ -1372,3 +1378,41 @@ EXPORT_SYMBOL(iw_handler_set_spy); EXPORT_SYMBOL(iw_handler_set_thrspy); EXPORT_SYMBOL(wireless_send_event); EXPORT_SYMBOL(wireless_spy_update); + +/*********************** WIRELESS OPS SUPPORT ***********************/ +/* + * Documentation to be added by Jeff ;-) + */ + +/*------------------------------------------------------------------*/ +/* + * Generic Wireless Handler to process Wireless Ops + */ +int iw_process_wireless_ops(struct net_device * dev, + struct iw_request_info *info, + union iwreq_data * wrqu, + char * extra) +{ + struct wireless_ops * ops; + + /* Already verified != NULL in get_handler() */ + ops = dev->wireless_handlers->wireless_ops; + + /* Just do it */ + switch(info->cmd) + { + case SIOCSIWESSID: + /* Set ESSID */ + if(ops->set_essid != NULL) + return ops->set_essid(dev, extra, wrqu->essid.length, + wrqu->essid.flags); + case SIOCGIWESSID: + /* Get ESSID */ + if(ops->get_essid != NULL) + return ops->get_essid(dev, extra, &wrqu->essid.length, + &wrqu->essid.flags); + default: + } + return -EOPNOTSUPP; +} + From davem@redhat.com Thu Jun 17 11:20:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:20:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HIKDgi029586 for ; Thu, 17 Jun 2004 11:20:14 -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 i5HIKAe1029551; Thu, 17 Jun 2004 14:20: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 i5HIKA023079; Thu, 17 Jun 2004 14:20:10 -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 i5HIJqCZ003051; Thu, 17 Jun 2004 14:19:52 -0400 Date: Thu, 17 Jun 2004 11:19:50 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.7] sparse annotation of csum_and_copy_to_user Message-Id: <20040617111950.4cb1c301.davem@redhat.com> In-Reply-To: <20040616152941.554fc23f@dell_ss3.pdx.osdl.net> References: <20040616152941.554fc23f@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6056 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: 26 Lines: 2 Applied, thanks Stephen. From jgarzik@pobox.com Thu Jun 17 11:26:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:26:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HIQXgi031380 for ; Thu, 17 Jun 2004 11:26:35 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb1aq-0004e7-Lh; Thu, 17 Jun 2004 19:26:32 +0100 Message-ID: <40D1E24C.8090802@pobox.com> Date: Thu, 17 Jun 2004 14:26:20 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: jt@hpl.hp.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> In-Reply-To: <40D1E185.2010201@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6057 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: 1013 Lines: 22 Jeff Garzik wrote: > struct wireless_ops { > int (*get_name) (struct net_device *dev, struct iw_request_info *info, > union iwreq_data *wrqu, char *extra); > int (*get_freq) (struct net_device *dev, struct iw_request_info *info, > union iwreq_data *wrqu, char *extra); > int (*set_freq) (struct net_device *dev, struct iw_request_info *info, > union iwreq_data *wrqu, char *extra); > int (*get_mode) (struct net_device *dev, struct iw_request_info *info, > union iwreq_data *wrqu, char *extra); > int (*set_mode) (struct net_device *dev, struct iw_request_info *info, > union iwreq_data *wrqu, char *extra); Note that the above is only a first step. Through the standard Linux development process -- evolution -- each hook can be pared down to precisely what each call needs. The above allows for a quick transition of drivers, while keeping them working. Jeff From gwingerde@home.nl Thu Jun 17 11:39:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:39:44 -0700 (PDT) Received: from smtpq2.home.nl (smtpq2.home.nl [213.51.128.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HIdegi032211 for ; Thu, 17 Jun 2004 11:39:41 -0700 Received: from [213.51.128.134] (port=33774 helo=smtp3.home.nl) by smtpq2.home.nl with esmtp (Exim 4.30) id 1Bb1nX-0003Ye-8l; Thu, 17 Jun 2004 20:39:39 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([212.120.112.51]:32961 helo=[192.168.14.1]) by smtp3.home.nl with esmtp (Exim 4.30) id 1Bb1nW-0007Nw-14; Thu, 17 Jun 2004 20:39:38 +0200 Message-ID: <40D1E350.6030509@home.nl> Date: Thu, 17 Jun 2004 20:30:40 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 0.6 (X11/20040526) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com, jt@hpl.hp.com, sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> In-Reply-To: <40D1E24C.8090802@pobox.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: 6058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Content-Length: 1506 Lines: 43 Jeff, I think I get the gist of it. I'll start working on this and produce some results in a few days. We can then review the results start discussing further directions/modifications. I'll leave netlink out of it right now (see the problems Jean had earlier), but I think that the basic approach (wireless_ops, etc.) can be reused within a netlink implementation anyway. --- Gertjan. Jeff Garzik wrote: > Jeff Garzik wrote: > >> struct wireless_ops { >> int (*get_name) (struct net_device *dev, struct iw_request_info >> *info, >> union iwreq_data *wrqu, char *extra); >> int (*get_freq) (struct net_device *dev, struct iw_request_info >> *info, >> union iwreq_data *wrqu, char *extra); >> int (*set_freq) (struct net_device *dev, struct iw_request_info >> *info, >> union iwreq_data *wrqu, char *extra); >> int (*get_mode) (struct net_device *dev, struct iw_request_info >> *info, >> union iwreq_data *wrqu, char *extra); >> int (*set_mode) (struct net_device *dev, struct iw_request_info >> *info, >> union iwreq_data *wrqu, char *extra); > > > > Note that the above is only a first step. Through the standard Linux > development process -- evolution -- each hook can be pared down to > precisely what each call needs. The above allows for a quick transition > of drivers, while keeping them working. > > Jeff > > > From shemminger@osdl.org Thu Jun 17 11:52:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:53:02 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HIqvgi000370 for ; Thu, 17 Jun 2004 11:52:58 -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 i5HIpur25544; Thu, 17 Jun 2004 11:51:56 -0700 Date: Thu, 17 Jun 2004 11:51:56 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com, jt@hpl.hp.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-Id: <20040617115156.14c946b5@dell_ss3.pdx.osdl.net> In-Reply-To: <40D1E24C.8090802@pobox.com> References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@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: 6059 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: 1284 Lines: 25 On Thu, 17 Jun 2004 14:26:20 -0400 Jeff Garzik wrote: > Jeff Garzik wrote: > > struct wireless_ops { > > int (*get_name) (struct net_device *dev, struct iw_request_info *info, > > union iwreq_data *wrqu, char *extra); > > int (*get_freq) (struct net_device *dev, struct iw_request_info *info, > > union iwreq_data *wrqu, char *extra); > > int (*set_freq) (struct net_device *dev, struct iw_request_info *info, > > union iwreq_data *wrqu, char *extra); > > int (*get_mode) (struct net_device *dev, struct iw_request_info *info, > > union iwreq_data *wrqu, char *extra); > > int (*set_mode) (struct net_device *dev, struct iw_request_info *info, > > union iwreq_data *wrqu, char *extra); > > > Note that the above is only a first step. Through the standard Linux > development process -- evolution -- each hook can be pared down to > precisely what each call needs. The above allows for a quick transition > of drivers, while keeping them working. Remember the API for applications (netlink) doesn't need to be the same as the driver interface (wireless_ops). That is the whole point of having a common core layer. From jt@bougret.hpl.hp.com Thu Jun 17 11:56:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 11:56:13 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HIu7gi000779 for ; Thu, 17 Jun 2004 11:56:07 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id EF03D1027E; Thu, 17 Jun 2004 11:56:06 -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 LAA11292; Thu, 17 Jun 2004 11:57:35 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb23S-0000AP-00; Thu, 17 Jun 2004 11:56:06 -0700 Date: Thu, 17 Jun 2004 11:56:05 -0700 To: Jeff Garzik Cc: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617185605.GA32216@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1E185.2010201@pobox.com> 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: 6060 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: 1271 Lines: 32 On Thu, Jun 17, 2004 at 02:23:01PM -0400, Jeff Garzik wrote: > Jean Tourrilhes wrote: > > > > As a matter of fact, I tried the strongly type approach you > >advocate and find its kernel overhead not acceptable. Note that people > >not using wireless have to suffer from this bloat, and wireless > >extensions are used in embeeded platforms such as OpenAP, iPaq and > >Zaurus where footprint matters. > > As you can see from the patch and header I have attached, there is > _zero_ change to storage. No additional bloat. I've never talked of driver bloat, which I don't really care about. I'm talking of *kernel* bloat. And not about storage bloat, but code bloat. When I designed the API, I did verify this carefully : http://marc.theaimsgroup.com/?l=linux-kernel&m=100829443600986&w=2 > Sorry, keeping compatibility with drivers outside the kernel is _not_ a > priority here. Backward compatibility is how this cruft accumulated in > the first place. > > Go ahead and assume that drivers outside the kernel will break. This is > no different from vendor drivers -- if the driver is not in the kernel, > it doesn't exist. Jeff, this is not the way I work. For example, there are good reasons why the Atheros driver is outside the kernel. > Jeff Jean From jt@bougret.hpl.hp.com Thu Jun 17 12:00:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:00:53 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJ0ogi001220 for ; Thu, 17 Jun 2004 12:00:50 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 47F8C999E; Thu, 17 Jun 2004 12:00:50 -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 MAA11392; Thu, 17 Jun 2004 12:02:19 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb281-0000Ar-00; Thu, 17 Jun 2004 12:00:49 -0700 Date: Thu, 17 Jun 2004 12:00:49 -0700 To: Stephen Hemminger Cc: Jeff Garzik , netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617190049.GC32216@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617115156.14c946b5@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617115156.14c946b5@dell_ss3.pdx.osdl.net> 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: 6061 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: 456 Lines: 12 On Thu, Jun 17, 2004 at 11:51:56AM -0700, Stephen Hemminger wrote: > > Remember the API for applications (netlink) doesn't need to be the same as > the driver interface (wireless_ops). That is the whole point of having > a common core layer. Stephen : we have been there since 2001. Check the RtNetlink patch on my web page, it allows full access to all wireless extensions through netlink without having to modify a single driver. Have fun... Jean From jgarzik@pobox.com Thu Jun 17 12:03:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:03: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.12.10/8.12.9) with SMTP id i5HJ32gi001562 for ; Thu, 17 Jun 2004 12:03:03 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb2A9-0005pl-ON; Thu, 17 Jun 2004 20:03:01 +0100 Message-ID: <40D1EAD9.6090403@pobox.com> Date: Thu, 17 Jun 2004 15:02:49 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617185815.GB32216@bougret.hpl.hp.com> In-Reply-To: <20040617185815.GB32216@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6062 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: 650 Lines: 22 Jean Tourrilhes wrote: > On Thu, Jun 17, 2004 at 02:26:20PM -0400, Jeff Garzik wrote: > >>Note that the above is only a first step. Through the standard Linux >>development process -- evolution -- each hook can be pared down to >>precisely what each call needs. The above allows for a quick transition >>of drivers, while keeping them working. >> >> Jeff > > > Have you looked at the patch I sent you ? In which way does it > fails to meet your need ? The three major problems I listed in a previous email are still present... Also there is a fourth -- WE doesn't work 100% when you have a 32-bit userland and a 64-bit kernel. Jeff From kuznet@ms2.inr.ac.ru Thu Jun 17 12:04:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:04:15 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJ49gi002234 for ; Thu, 17 Jun 2004 12:04:10 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id XAA11278; Thu, 17 Jun 2004 23:01:58 +0400 Date: Thu, 17 Jun 2004 23:01:58 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040617190158.GA10925@ms2.inr.ac.ru> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616231317.GA5742@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6064 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 963 Lines: 25 Hello! > The problem is that each bundle can have only one PMTU. But > there can be an arbitrary number of paths over each bundle. Seems, I still do not understand what you mean. Returning to the beginning: > But this is wrong because it assigns > a single MTU to all hosts behind an IPsec gateway, even though their > paths may well diverge beyond the gateway. Diverge where exactly? On path where packets are transformed? PMTU discovery cannot do something clever for this case: we receive only small piece of transformed datagram, in the best case with SPI in it, so we can only update pmtu not even on bundle, but on even wider aggregate, on SA itself. This part is missing now, by the way, it is to be done inside error handlers in transformations. From another hand, if it is an ICMP from beyond another end of tunnel, it is problem of original senders to handle them. Gateways even do not see such ICMPs, which are destined not for them. Alexey From geert@linux-m68k.org Thu Jun 17 12:05:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:06:04 -0700 (PDT) Received: from witte.sonytel.be (witte.sonytel.be [80.88.33.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJ5ugi002616 for ; Thu, 17 Jun 2004 12:05:57 -0700 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5HJ5pXK006049; Thu, 17 Jun 2004 21:05:52 +0200 (MEST) Date: Thu, 17 Jun 2004 21:05:51 +0200 (MEST) From: Geert Uytterhoeven To: Marcelo Tosatti , "David S. Miller" cc: Linux Kernel Development , netdev@oss.sgi.com Subject: igmp warning (was: Re: Linux 2.4.27-pre6) In-Reply-To: Message-ID: References: <20040616183343.GA9940@logos.cnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6065 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: netdev Content-Length: 1072 Lines: 38 And this is a new one (compared to -pre3): | igmp.c: In function `igmpv3_newpack': | igmp.c:279: warning: `skb' might be used uninitialized in this function And it seems to be a real bug, not a compiler glitch: | static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size) | { | struct sk_buff *skb; ^^^ | struct rtable *rt; | struct iphdr *pip; | struct igmpv3_report *pig; | u32 dst; | | dst = IGMPV3_ALL_MCR; | if (ip_route_output(&rt, dst, 0, 0, dev->ifindex)) | return 0; | if (rt->rt_src == 0) { | kfree_skb(skb); ^^^ | ip_rt_put(rt); | return 0; | } Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From davem@redhat.com Thu Jun 17 12:09:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:09:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJ9ggi003142 for ; Thu, 17 Jun 2004 12:09:43 -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 i5HJ9Ye1011828; Thu, 17 Jun 2004 15:09:34 -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 i5HJ9Y011160; Thu, 17 Jun 2004 15:09:34 -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 i5HJ9Gjg006249; Thu, 17 Jun 2004 15:09:16 -0400 Date: Thu, 17 Jun 2004 12:09:14 -0700 From: "David S. Miller" To: Geert Uytterhoeven Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: igmp warning (was: Re: Linux 2.4.27-pre6) Message-Id: <20040617120914.2e70f768.davem@redhat.com> In-Reply-To: References: <20040616183343.GA9940@logos.cnet> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6066 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: 111 Lines: 5 Indeed, a 2.6.x bugfix got put into 2.4.x but it was not relevant there at all. Will fix this, thanks Geert. From kuznet@ms2.inr.ac.ru Thu Jun 17 12:09:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:09:52 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJ9mgi003182 for ; Thu, 17 Jun 2004 12:09:49 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id XAA11307; Thu, 17 Jun 2004 23:07:39 +0400 Date: Thu, 17 Jun 2004 23:07:39 +0400 From: Alexey Kuznetsov To: "David S. Miller" Cc: herbert@gondor.apana.org.au, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040617190739.GB10925@ms2.inr.ac.ru> References: <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> <20040617083303.GA8810@gondor.apana.org.au> <20040617101016.44512cb1.davem@redhat.com> <20040617172449.GA10303@ms2.inr.ac.ru> <20040617105324.554c631b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617105324.554c631b.davem@redhat.com> User-Agent: Mutt/1.5.6i X-archive-position: 6067 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 285 Lines: 13 Hello! > It occurs, via synchronize_net(), but this happens before NETDEV_UNREGISTER > event is sent out. Is it sufficient? I think not, Agreed. > and that we need to > add another call in unregister_netdevice() right before final dev_put(). This should be enough. Alexey From jgarzik@pobox.com Thu Jun 17 12:10:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:10:50 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJAlgi003808 for ; Thu, 17 Jun 2004 12:10:48 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb2He-0005uj-Ni; Thu, 17 Jun 2004 20:10:46 +0100 Message-ID: <40D1ECAA.4090509@pobox.com> Date: Thu, 17 Jun 2004 15:10:34 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Stephen Hemminger , netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617115156.14c946b5@dell_ss3.pdx.osdl.net> <20040617190049.GC32216@bougret.hpl.hp.com> In-Reply-To: <20040617190049.GC32216@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6068 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: 638 Lines: 21 Jean Tourrilhes wrote: > On Thu, Jun 17, 2004 at 11:51:56AM -0700, Stephen Hemminger wrote: > >>Remember the API for applications (netlink) doesn't need to be the same as >>the driver interface (wireless_ops). That is the whole point of having >>a common core layer. > > > Stephen : we have been there since 2001. Check the RtNetlink > patch on my web page, it allows full access to all wireless extensions > through netlink without having to modify a single driver. Nod... here's hoping others are checking out out too. As Stephen points out, though, the driver interface redesign is separate from the use of netlink. Jeff From davem@redhat.com Thu Jun 17 12:16:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:16:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJGqgi004564 for ; Thu, 17 Jun 2004 12:16: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 i5HJGde1014076; Thu, 17 Jun 2004 15:16:39 -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 i5HJGd013723; Thu, 17 Jun 2004 15:16:39 -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 i5HJGLOD014822; Thu, 17 Jun 2004 15:16:21 -0400 Date: Thu, 17 Jun 2004 12:16:18 -0700 From: "David S. Miller" To: Alexey Kuznetsov Cc: herbert@gondor.apana.org.au, schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-Id: <20040617121618.12fe245b.davem@redhat.com> In-Reply-To: <20040617190739.GB10925@ms2.inr.ac.ru> References: <20040614124402.GA28519@gondor.apana.org.au> <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> <20040617083303.GA8810@gondor.apana.org.au> <20040617101016.44512cb1.davem@redhat.com> <20040617172449.GA10303@ms2.inr.ac.ru> <20040617105324.554c631b.davem@redhat.com> <20040617190739.GB10925@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6069 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: 260 Lines: 9 On Thu, 17 Jun 2004 23:07:39 +0400 Alexey Kuznetsov wrote: > > and that we need to > > add another call in unregister_netdevice() right before final dev_put(). > > This should be enough. Perfect, that's what I'll do in my tree. From jgarzik@pobox.com Thu Jun 17 12:18:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:18:45 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJIdgi004901 for ; Thu, 17 Jun 2004 12:18:40 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb1Xe-0004MZ-K9; Thu, 17 Jun 2004 19:23:15 +0100 Message-ID: <40D1E185.2010201@pobox.com> Date: Thu, 17 Jun 2004 14:23:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> In-Reply-To: <20040617174717.GA30460@bougret.hpl.hp.com> Content-Type: multipart/mixed; boundary="------------050606090300090402020100" X-archive-position: 6070 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: 10207 Lines: 243 This is a multi-part message in MIME format. --------------050606090300090402020100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jean Tourrilhes wrote: > On Wed, Jun 16, 2004 at 07:06:13PM -0400, Jeff Garzik wrote: > >>It's not Jeff's weird personal preference that iw_handler be killed... >>type-opaque interfaces cause real problems. A good C programmer should >>very, very rarely use type-casting. > > > Yes, I know that I am really a perverse mind and I did > designed the API this way only to make your life miserable and to > sabotage the Linux kernel. > > As a matter of fact, I tried the strongly type approach you > advocate and find its kernel overhead not acceptable. Note that people > not using wireless have to suffer from this bloat, and wireless > extensions are used in embeeded platforms such as OpenAP, iPaq and > Zaurus where footprint matters. As you can see from the patch and header I have attached, there is _zero_ change to storage. No additional bloat. > Now, it seems that you clearly have not understood my > proposal, so I made a little patch, hopping that it will clear the > obvious miscommunication. Patch is below. > I hope you will notice that the changes are fairly trivial and > clean. And it's backward compatible. > I also want you to notice that the code is quasi optimal, > compared to rewritting the API, there is only one additional function > call (plus the backward compatibility). I know you won't believe me, > so verify that yourself. I think this is a small price to pay for > keeping backward compatibility with all those drivers outside the > kernel (see my web page). Sorry, keeping compatibility with drivers outside the kernel is _not_ a priority here. Backward compatibility is how this cruft accumulated in the first place. Go ahead and assume that drivers outside the kernel will break. This is no different from vendor drivers -- if the driver is not in the kernel, it doesn't exist. Jeff --------------050606090300090402020100 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" ===== drivers/net/wireless/wl3501_cs.c 1.77 vs edited ===== --- 1.77/drivers/net/wireless/wl3501_cs.c 2004-06-03 21:38:07 -04:00 +++ edited/drivers/net/wireless/wl3501_cs.c 2004-06-16 19:42:10 -04:00 @@ -46,6 +46,7 @@ #include #include #include +#include #include @@ -1959,38 +1960,37 @@ return rc; } -static const iw_handler wl3501_handler[] = { - [SIOCGIWNAME - SIOCIWFIRST] = wl3501_get_name, - [SIOCSIWFREQ - SIOCIWFIRST] = wl3501_set_freq, - [SIOCGIWFREQ - SIOCIWFIRST] = wl3501_get_freq, - [SIOCSIWMODE - SIOCIWFIRST] = wl3501_set_mode, - [SIOCGIWMODE - SIOCIWFIRST] = wl3501_get_mode, - [SIOCGIWSENS - SIOCIWFIRST] = wl3501_get_sens, - [SIOCGIWRANGE - SIOCIWFIRST] = wl3501_get_range, - [SIOCSIWSPY - SIOCIWFIRST] = iw_handler_set_spy, - [SIOCGIWSPY - SIOCIWFIRST] = iw_handler_get_spy, - [SIOCSIWTHRSPY - SIOCIWFIRST] = iw_handler_set_thrspy, - [SIOCGIWTHRSPY - SIOCIWFIRST] = iw_handler_get_thrspy, - [SIOCSIWAP - SIOCIWFIRST] = wl3501_set_wap, - [SIOCGIWAP - SIOCIWFIRST] = wl3501_get_wap, - [SIOCSIWSCAN - SIOCIWFIRST] = wl3501_set_scan, - [SIOCGIWSCAN - SIOCIWFIRST] = wl3501_get_scan, - [SIOCSIWESSID - SIOCIWFIRST] = wl3501_set_essid, - [SIOCGIWESSID - SIOCIWFIRST] = wl3501_get_essid, - [SIOCSIWNICKN - SIOCIWFIRST] = wl3501_set_nick, - [SIOCGIWNICKN - SIOCIWFIRST] = wl3501_get_nick, - [SIOCGIWRATE - SIOCIWFIRST] = wl3501_get_rate, - [SIOCGIWRTS - SIOCIWFIRST] = wl3501_get_rts_threshold, - [SIOCGIWFRAG - SIOCIWFIRST] = wl3501_get_frag_threshold, - [SIOCGIWTXPOW - SIOCIWFIRST] = wl3501_get_txpow, - [SIOCGIWRETRY - SIOCIWFIRST] = wl3501_get_retry, - [SIOCGIWENCODE - SIOCIWFIRST] = wl3501_get_encode, - [SIOCGIWPOWER - SIOCIWFIRST] = wl3501_get_power, +static const struct wireless_ops wl3501_ops = { + .get_name = wl3501_get_name, + .get_freq = wl3501_get_freq, + .set_freq = wl3501_set_freq, + .set_mode = wl3501_set_mode, + .get_mode = wl3501_get_mode, + .get_sens = wl3501_get_sens, + .get_range = wl3501_get_range, + .set_spy = iw_handler_set_spy, + .get_spy = iw_handler_get_spy, + .set_thrspy = iw_handler_set_thrspy, + .get_thrspy = iw_handler_get_thrspy, + .set_wap = wl3501_set_wap, + .get_wap = wl3501_get_wap, + .set_scan = wl3501_set_scan, + .get_scan = wl3501_get_scan, + .set_essid = wl3501_set_essid, + .get_essid = wl3501_get_essid, + .set_nick = wl3501_set_nick, + .get_nick = wl3501_get_nick, + .get_rate = wl3501_get_rate, + .get_rts_threshold = wl3501_get_rts_threshold, + .get_frag_threshold = wl3501_get_frag_threshold, + .get_txpow = wl3501_get_txpow, + .get_retry = wl3501_get_retry, + .get_encode = wl3501_get_encode, + .get_power = wl3501_get_power, }; -static const struct iw_handler_def wl3501_handler_def = { - .num_standard = sizeof(wl3501_handler) / sizeof(iw_handler), - .standard = (iw_handler *)wl3501_handler, +static const struct wireless_handler wl3501_handler = { + .ops = &wl3501_ops, .spy_offset = offsetof(struct wl3501_card, spy_data), }; @@ -2048,7 +2048,7 @@ dev->get_stats = wl3501_get_stats; dev->get_wireless_stats = wl3501_get_wireless_stats; dev->do_ioctl = wl3501_ioctl; - dev->wireless_handlers = (struct iw_handler_def *)&wl3501_handler_def; + dev->wireless_handler = &wl3501_handler; netif_stop_queue(dev); link->priv = link->irq.Instance = dev; ===== include/linux/netdevice.h 1.80 vs edited ===== --- 1.80/include/linux/netdevice.h 2004-06-04 01:02:47 -04:00 +++ edited/include/linux/netdevice.h 2004-06-16 19:42:38 -04:00 @@ -41,6 +41,7 @@ struct divert_blk; struct vlan_group; struct ethtool_ops; +struct wireless_handler; /* source back-compat hooks */ #define SET_ETHTOOL_OPS(netdev,ops) \ @@ -304,7 +305,7 @@ /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct wireless_handler *wireless_handler; struct ethtool_ops *ethtool_ops; --------------050606090300090402020100 Content-Type: text/x-chdr; name="wifi.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="wifi.h" #ifndef __LINUX_WIFI_H__ #define __LINUX_WIFI_H__ #include struct wireless_ops { int (*get_name) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_freq) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_freq) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_mode) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_mode) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_sens) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_range) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_spy) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_spy) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_thrspy) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_thrspy) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_wap) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_wap) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_scan) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_scan) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_essid) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_essid) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_nick) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*set_nick) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_rate) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_rts_threshold) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_frag_threshold) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_txpow) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_retry) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_encode) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); int (*get_power) (struct net_device *dev, struct iw_request_info *info, union iwreq_data *wrqu, char *extra); }; struct wireless_handler { const struct wireless_ops *ops; size_t spy_offset; }; #endif /* __LINUX_WIFI_H__ */ --------------050606090300090402020100-- From jt@bougret.hpl.hp.com Thu Jun 17 12:32:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:32:06 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJW2gi008752 for ; Thu, 17 Jun 2004 12:32:03 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id AEA4F11803; Thu, 17 Jun 2004 12:32: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 MAA12123; Thu, 17 Jun 2004 12:33:24 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb2c6-0000Pm-00; Thu, 17 Jun 2004 12:31:54 -0700 Date: Thu, 17 Jun 2004 12:31:54 -0700 To: Jeff Garzik Cc: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617193154.GE32216@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> <40D1EC54.8000904@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1EC54.8000904@pobox.com> 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: 6072 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: 2156 Lines: 51 On Thu, Jun 17, 2004 at 03:09:08PM -0400, Jeff Garzik wrote: > > > When I designed the API, I did verify this carefully : > > http://marc.theaimsgroup.com/?l=linux-kernel&m=100829443600986&w=2 > > This WAS a step forward, and this will help greatly in the > implementation of wireless_ops. It's good stuff, but we are moving > forward yet again :) And guess what, I'm helping you in the process. Look back at all the e-mail I sent to the various thread on the subject, and you will clearly see that I'm constructive and giving suggestion on how to do best in this process. I even provide patches. I don't understand why you are so opposed to my suggestions, and what more you expect from me. > If a driver isn't in the kernel, it's the responsibility of the vendor > to follow the changes in the kernel. It's not the kernel developer's > responsibility to track random stuff posted on web pages. That's simply > not scalable. The wireless extension has remained backward compatible over almost 8 years, while tremendously improving and adding new features. And I believe that moving forward, the price of keeping backward compatibility is small, as you can see from my patch. It's possible. It's not difficult. Breaking backward compatibility is not a design goal. > I imagine this is another area where we must agree to disagree. Linux > kernel development has always focused on in-tree drivers. > > Wireless traditionally has had a lot of drivers out-of-tree -- and being > out of tree, we see what happens: vendors are encouraged to mixed > binary-only drivers, multiple wireless stacks appears, and confusion > reigned. Jeff, as you know it, I personally added more wireless driver to the Linux kernel than any other person, for all those reasons. Look at how Luis R. Rodriguez blame me to have pushed his driver in the kernel. I've given you plenty of advices on how to move forward with the in-kernel 802.11 stack, and some of those advices may even have been helpful. So, what are you blaming me of ? > It's now time for convergence :) Converging wireless into Linux since 1996. Welcome to the club ;-) > Jeff Jean From jt@bougret.hpl.hp.com Thu Jun 17 12:31:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:31:42 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJVUgi008623 for ; Thu, 17 Jun 2004 12:31:30 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id F197F4084AF; Thu, 17 Jun 2004 11:58:15 -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 LAA11347; Thu, 17 Jun 2004 11:59:44 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb25X-0000Af-00; Thu, 17 Jun 2004 11:58:15 -0700 Date: Thu, 17 Jun 2004 11:58:15 -0700 To: Jeff Garzik Cc: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617185815.GB32216@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1E24C.8090802@pobox.com> 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: 6071 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: 434 Lines: 13 On Thu, Jun 17, 2004 at 02:26:20PM -0400, Jeff Garzik wrote: > > Note that the above is only a first step. Through the standard Linux > development process -- evolution -- each hook can be pared down to > precisely what each call needs. The above allows for a quick transition > of drivers, while keeping them working. > > Jeff Have you looked at the patch I sent you ? In which way does it fails to meet your need ? Jean From jt@bougret.hpl.hp.com Thu Jun 17 12:44:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:44:58 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJisgi009844 for ; Thu, 17 Jun 2004 12:44:54 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 842431C0FF5E; Thu, 17 Jun 2004 12:44:54 -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 MAA12420; Thu, 17 Jun 2004 12:46:18 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb2oa-0000XH-00; Thu, 17 Jun 2004 12:44:48 -0700 Date: Thu, 17 Jun 2004 12:44:48 -0700 To: Jeff Garzik Cc: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617194448.GC31763@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617185815.GB32216@bougret.hpl.hp.com> <40D1EAD9.6090403@pobox.com> <20040617191338.GD32216@bougret.hpl.hp.com> <40D1F23E.9090307@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1F23E.9090307@pobox.com> 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: 6073 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: 1142 Lines: 38 On Thu, Jun 17, 2004 at 03:34:22PM -0400, Jeff Garzik wrote: > > Your patch is half the job -- it allows development of a type-specific > interface... Which is exactly what you want. Good. > So while this patch may be useful in early development, it does not > allow the direct exposure of core wireless code to the type-specific > interfaces What is the core wireless code ? > and as such, it can paper over problems that would be > immediately obviously if the type-specific interface were the only one > to exist. Any new code in the kernel is free to use only the new API. That's a big enoug incentive to migrate drivers over to the new API. > >>Also there is a fourth -- WE doesn't work 100% when you have > >>a 32-bit userland and a 64-bit kernel. > > > > > > Since when ? What made you change your mind ? > > Please check : > >http://marc.theaimsgroup.com/?l=linux-netdev&m=107894322418086&w=2 > > The general API, yes. But most driver-private interfaces will fail > miserably through 32/64-bit translation. That's fixable, and easy to fix, if needed. You have all the data you need in the kernel. > Jeff Jean From jt@bougret.hpl.hp.com Thu Jun 17 12:48:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:48:07 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJllgi010244 for ; Thu, 17 Jun 2004 12:47:51 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 28C76134F1; Thu, 17 Jun 2004 12:13:39 -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 MAA11722; Thu, 17 Jun 2004 12:15:08 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb2KQ-0000IC-00; Thu, 17 Jun 2004 12:13:38 -0700 Date: Thu, 17 Jun 2004 12:13:38 -0700 To: Jeff Garzik Cc: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617191338.GD32216@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617185815.GB32216@bougret.hpl.hp.com> <40D1EAD9.6090403@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1EAD9.6090403@pobox.com> 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: 6074 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: 3255 Lines: 108 On Thu, Jun 17, 2004 at 03:02:49PM -0400, Jeff Garzik wrote: > Jean Tourrilhes wrote: > >On Thu, Jun 17, 2004 at 02:26:20PM -0400, Jeff Garzik wrote: > > > >>Note that the above is only a first step. Through the standard Linux > >>development process -- evolution -- each hook can be pared down to > >>precisely what each call needs. The above allows for a quick transition > >>of drivers, while keeping them working. > >> > >> Jeff > > > > > > Have you looked at the patch I sent you ? In which way does it > >fails to meet your need ? > > > The three major problems I listed in a previous email are still > present... Are we talking of the same patch ? I'm talking of this patch : http://marc.theaimsgroup.com/?l=linux-netdev&m=108749580004668&w=2 I reattached the patch below. It's short enough. > Also there is a fourth -- WE doesn't work 100% when you have > a 32-bit userland and a 64-bit kernel. Since when ? What made you change your mind ? Please check : http://marc.theaimsgroup.com/?l=linux-netdev&m=107894322418086&w=2 > Jeff Jean ----------------------------------------------------------- --- linux/include/net/iw_handler.j1.h Thu Jun 17 10:16:22 2004 +++ linux/include/net/iw_handler.h Thu Jun 17 10:17:24 2004 @@ -301,6 +301,9 @@ typedef int (*iw_handler)(struct net_dev */ struct iw_handler_def { + /* Wireless Ops definitions */ + struct wireless_ops * wireless_ops; + /* Number of handlers defined (more precisely, index of the * last defined handler + 1) */ __u16 num_standard; --- linux/net/core/wireless.j1.c Thu Jun 17 10:08:45 2004 +++ linux/net/core/wireless.c Thu Jun 17 10:28:59 2004 @@ -343,8 +343,14 @@ static inline iw_handler get_handler(str if(dev->wireless_handlers == NULL) return NULL; - /* Try as a standard command */ index = cmd - SIOCIWFIRST; + + /* Try as wireless_ops */ + if((index < (SIOCIWFIRSTPRIV - SIOCIWFIRST)) && + (dev->wireless_handlers->wireless_ops != NULL)) + return &iw_process_wireless_ops; + + /* Try as a standard command */ if(index < dev->wireless_handlers->num_standard) return dev->wireless_handlers->standard[index]; @@ -1372,3 +1378,41 @@ EXPORT_SYMBOL(iw_handler_set_spy); EXPORT_SYMBOL(iw_handler_set_thrspy); EXPORT_SYMBOL(wireless_send_event); EXPORT_SYMBOL(wireless_spy_update); + +/*********************** WIRELESS OPS SUPPORT ***********************/ +/* + * Documentation to be added by Jeff ;-) + */ + +/*------------------------------------------------------------------*/ +/* + * Generic Wireless Handler to process Wireless Ops + */ +int iw_process_wireless_ops(struct net_device * dev, + struct iw_request_info *info, + union iwreq_data * wrqu, + char * extra) +{ + struct wireless_ops * ops; + + /* Already verified != NULL in get_handler() */ + ops = dev->wireless_handlers->wireless_ops; + + /* Just do it */ + switch(info->cmd) + { + case SIOCSIWESSID: + /* Set ESSID */ + if(ops->set_essid != NULL) + return ops->set_essid(dev, extra, wrqu->essid.length, + wrqu->essid.flags); + case SIOCGIWESSID: + /* Get ESSID */ + if(ops->get_essid != NULL) + return ops->get_essid(dev, extra, &wrqu->essid.length, + &wrqu->essid.flags); + default: + } + return -EOPNOTSUPP; +} + From jgarzik@pobox.com Thu Jun 17 12:52:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 12:52:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HJqrgi010652 for ; Thu, 17 Jun 2004 12:52:54 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb2wO-00070T-Ao; Thu, 17 Jun 2004 20:52:52 +0100 Message-ID: <40D1F687.6030307@pobox.com> Date: Thu, 17 Jun 2004 15:52:39 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> <40D1EC54.8000904@pobox.com> <20040617193154.GE32216@bougret.hpl.hp.com> In-Reply-To: <20040617193154.GE32216@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6075 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: 1772 Lines: 39 Jean Tourrilhes wrote: > And guess what, I'm helping you in the process. Look back at > all the e-mail I sent to the various thread on the subject, and you > will clearly see that I'm constructive and giving suggestion on how to > do best in this process. I even provide patches. > I don't understand why you are so opposed to my suggestions, > and what more you expect from me. [...] > Converging wireless into Linux since 1996. Welcome to the club ;-) hehe :) I'm _not_ blaming you for anything. You have certainly contributed a lot. I've enjoyed working with you in the past, today, and hopefully into the future as well. I _am_ listening. But I think we have a fundamental disagreement: I feel strongly (as you see :)) that the type-opaque interface has got to go, and that means breaking backwards compatibility in the driver API. The iw_handler interface breaks rules of C that we shouldn't be breaking. Today's kernel includes boatloads of reference-counted kobjects, with strict definitions of lifetime rules. This has exposed endless bugs and caused a lot of pain, but overall it's a good thing to clean all that up. Interfaces that store offsets into driver-local structures (iw_handler_def) violate these lifetime rules by simply assuming you always have access to the structure of choice. We want to design driver interfaces that make it tough for the driver writer to screw up. Excluding yourself, myself, and others on this list, I think we all know that driver writers can't code their way out of a paper bag. A properly designed interface lets the compiler flag incorrect code at the first possible opportunity. Current WE __does__ get the job done (kudos), but it simply doesn't afford that kind of protection. Jeff From jgarzik@pobox.com Thu Jun 17 13:06:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 13:06:44 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HK6dgi011420 for ; Thu, 17 Jun 2004 13:06:39 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb39i-0007gY-2e; Thu, 17 Jun 2004 21:06:38 +0100 Message-ID: <40D1F9C1.1040907@pobox.com> Date: Thu, 17 Jun 2004 16:06:25 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617185815.GB32216@bougret.hpl.hp.com> <40D1EAD9.6090403@pobox.com> <20040617191338.GD32216@bougret.hpl.hp.com> <40D1F23E.9090307@pobox.com> <20040617194448.GC31763@bougret.hpl.hp.com> In-Reply-To: <20040617194448.GC31763@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6076 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: 1883 Lines: 63 Jean Tourrilhes wrote: > On Thu, Jun 17, 2004 at 03:34:22PM -0400, Jeff Garzik wrote: > >>Your patch is half the job -- it allows development of a type-specific >>interface... > > > Which is exactly what you want. Good. The patch doesn't kill the type-opaque interface, so only 50% of what I want. >>So while this patch may be useful in early development, it does not >>allow the direct exposure of core wireless code to the type-specific >>interfaces > > > What is the core wireless code ? At the moment, "the stuff that calls the driver-local iw_handlers", but hopefully more generic wireless core soon with the merge of HostAP. >>and as such, it can paper over problems that would be >>immediately obviously if the type-specific interface were the only one >>to exist. > > > Any new code in the kernel is free to use only the new > API. That's a big enoug incentive to migrate drivers over to the new > API. With the type-opaque interface gone (key design goal), drivers not using the new API will not function... >>>>Also there is a fourth -- WE doesn't work 100% when you have >>>>a 32-bit userland and a 64-bit kernel. >>> >>> >>> Since when ? What made you change your mind ? >>> Please check : >>>http://marc.theaimsgroup.com/?l=linux-netdev&m=107894322418086&w=2 >> >>The general API, yes. But most driver-private interfaces will fail >>miserably through 32/64-bit translation. > > > That's fixable, and easy to fix, if needed. You have all the > data you need in the kernel. Not really -- it's the same problem as SIOCDEVPRIVATE. Driver-private interfaces by definition change for each driver. Translation of the same ioctl differs on a per-driver basis. Consider what happens when passing pointers from userland, for example... It was for this reason that we created the MII ioctls, which were previously SIOCDEVPRIVATE. Jeff From jgarzik@pobox.com Thu Jun 17 13:13:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 13:13: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.12.10/8.12.9) with SMTP id i5HKDJgi012189 for ; Thu, 17 Jun 2004 13:13:20 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb3GA-00081P-Ha for netdev@oss.sgi.com; Thu, 17 Jun 2004 21:13:18 +0100 Message-ID: <40D1FB52.3060306@pobox.com> Date: Thu, 17 Jun 2004 16:13:06 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Wireless-2.6 queue updated Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6077 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: 194 Lines: 10 Minor update, just re-syncing to 2.6.7. Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.7-wireless1.patch.bz2 BitKeeper: bk://gkernel.bkbits.net/wireless-2.6 From jt@bougret.hpl.hp.com Thu Jun 17 13:39:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 13:39:33 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HKdUgi013449 for ; Thu, 17 Jun 2004 13:39:30 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 12E8E1C11369; Thu, 17 Jun 2004 13:39: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 NAA13761; Thu, 17 Jun 2004 13:40:58 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb3fV-0000ym-00; Thu, 17 Jun 2004 13:39:29 -0700 Date: Thu, 17 Jun 2004 13:39:29 -0700 To: Jeff Garzik Cc: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617203929.GA3341@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617185815.GB32216@bougret.hpl.hp.com> <40D1EAD9.6090403@pobox.com> <20040617191338.GD32216@bougret.hpl.hp.com> <40D1F23E.9090307@pobox.com> <20040617194448.GC31763@bougret.hpl.hp.com> <40D1F9C1.1040907@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1F9C1.1040907@pobox.com> 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: 6078 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: 1125 Lines: 30 On Thu, Jun 17, 2004 at 04:06:25PM -0400, Jeff Garzik wrote: > > >>The general API, yes. But most driver-private interfaces will fail > >>miserably through 32/64-bit translation. > > > > > > That's fixable, and easy to fix, if needed. You have all the > >data you need in the kernel. > > Not really -- it's the same problem as SIOCDEVPRIVATE. Driver-private > interfaces by definition change for each driver. Translation of the > same ioctl differs on a per-driver basis. Consider what happens when > passing pointers from userland, for example... I can assure you that I thought about that precise issue when I re-designed the API in 91. I confirm that all the necessary data in the kernel to do this properly. Proof : the "copy_to/from_user" is done in the generic code, not in the driver. The driver export to the generic code all the data needed to know where are those user pointers. What else is needed ? > It was for this reason that we created the MII ioctls, which were > previously SIOCDEVPRIVATE. Totally different business. Those ioctls were totally anonymous, with no meta-data. > Jeff Jean From jt@bougret.hpl.hp.com Thu Jun 17 13:46:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 13:46:53 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HKkogi013912 for ; Thu, 17 Jun 2004 13:46:50 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 51FA240AEFA; Thu, 17 Jun 2004 13:46:50 -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 NAA13929; Thu, 17 Jun 2004 13:48:14 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bb3mW-0000zD-00; Thu, 17 Jun 2004 13:46:44 -0700 Date: Thu, 17 Jun 2004 13:46:44 -0700 To: Jeff Garzik Cc: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-ID: <20040617204644.GB3341@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> <40D1EC54.8000904@pobox.com> <20040617193154.GE32216@bougret.hpl.hp.com> <40D1F687.6030307@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D1F687.6030307@pobox.com> 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: 6079 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: 870 Lines: 21 On Thu, Jun 17, 2004 at 03:52:39PM -0400, Jeff Garzik wrote: > > I'm _not_ blaming you for anything. You have certainly contributed a > lot. I've enjoyed working with you in the past, today, and hopefully > into the future as well. I _am_ listening. But I think we have a > fundamental disagreement: > > I feel strongly (as you see :)) that the type-opaque interface has got > to go, and that means breaking backwards compatibility in the driver API. Jeff, the main disagreement is not about type-opaque versus strongly-typed interfaces. I gave you a patch to do that, and I told you you were free to do it the way you want, I would not get in the way. The main disagreement is about backward compatibility. I've been fighting for 8 years to maintain backward compatibility. I believe in it, and I not accept gutting it for no good reasons. > Jeff Jean From jketreno@linux.jf.intel.com Thu Jun 17 13:48:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 13:48:08 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HKm7gi014231 for ; Thu, 17 Jun 2004 13:48:08 -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 i5HKnZwE004512 for ; Thu, 17 Jun 2004 20:49:38 GMT Received: from linux.jf.intel.com (fm-0a130f57-dhcp-client.fm.intel.com [10.19.15.87]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with ESMTP id i5HKhJRZ014992 for ; Thu, 17 Jun 2004 20:43:19 GMT Message-ID: <40D20373.3020406@linux.jf.intel.com> Date: Thu, 17 Jun 2004 15:47:47 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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 Subject: wireless management... kernel or user space? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 6080 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.jf.intel.com Precedence: bulk X-list: netdev Content-Length: 1461 Lines: 33 With the various discussions going on about a generic 802.11 frame/management stack, and the recent thread on wireless extensions, I wanted to find out what people's thoughts are on where wireless management should occur -- kernel or user space... Within the hostap project there exists the ability to have some AP management occur internal to the driver or (via the PRISM2_NO_KERNEL_IEEE80211_MGMT define) in a user space daemon. Does anyone have any thoughts on how much logic should be placed into the generic 802.11 frame/management/control handling stack vs. pushing to a user space component? If (for example) AP associate request / response policy is pushed to a user space component, by what mechanism does it make sense for the driver/application to send/receive the 802.11 frames? Are people happy with the way Host AP currently does it, or is there a better way? Other types of policy that could occur in user space would be for scan requests, probe response collection, AP selection to associate, etc. What is the general direction the wireless networking stack should take? Minimize kernel side wherever possible? With ipw2100 (and I believe other cards) the hw/fw handles a lot of the above internally, so the mechanism by which the user space application communicates with the driver would need allow for hw/fw capabilities to be exposed so the user doesn't get a broken experience. Thoughts? James (of ipw2100.sf.net) From jeb.j.cramer@intel.com Thu Jun 17 14:21:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 14:21:52 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HLLngi015631 for ; Thu, 17 Jun 2004 14:21:49 -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 i5G5Y6NF005817; Wed, 16 Jun 2004 05:34:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5G5RVmK014417; Wed, 16 Jun 2004 05:28:01 GMT Received: from mini.jf.intel.com ([134.134.3.156]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061522322317276 ; Tue, 15 Jun 2004 22:32:23 -0700 Subject: [PATCH 1/1 2.6] e1000 management reset fix From: Jeb Cramer To: jgarzik@pobox.com, netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Jun 2004 21:43:33 -0700 Message-Id: <1087361013.12233.14.camel@mini> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 6081 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeb.j.cramer@intel.com Precedence: bulk X-list: netdev Content-Length: 3402 Lines: 122 * Resetting the adapter blew away management settings. So we save the important bits before performing a reset. ------------------------------------------------------- diff -Nuarp --- A/drivers/net/e1000/e1000.h +++ B/drivers/net/e1000/e1000.h @@ -196,6 +196,7 @@ struct e1000_adapter { uint32_t part_num; uint32_t wol; uint32_t smartspeed; + uint32_t en_mng_pt; uint16_t link_speed; uint16_t link_duplex; spinlock_t stats_lock; diff -Nuarp --- A/drivers/net/e1000/e1000_hw.c +++ B/drivers/net/e1000/e1000_hw.c @@ -265,6 +265,17 @@ e1000_set_mac_type(struct e1000_hw *hw) return -E1000_ERR_MAC_TYPE; } + switch(hw->mac_type) { + case e1000_82541: + case e1000_82547: + case e1000_82541_rev_2: + case e1000_82547_rev_2: + hw->asf_firmware_present = TRUE; + break; + default: + break; + } + return E1000_SUCCESS; } @@ -5189,3 +5200,27 @@ e1000_set_vco_speed(struct e1000_hw *hw) return E1000_SUCCESS; } +/****************************************************************************** + * Verifies the hardware needs to allow ARPs to be processed by the host + * + * hw - Struct containing variables accessed by shared code + * + * returns: - TRUE/FALSE + * + *****************************************************************************/ +uint32_t +e1000_enable_mng_pass_thru(struct e1000_hw *hw) +{ + uint32_t manc; + + if (hw->asf_firmware_present) { + manc = E1000_READ_REG(hw, MANC); + + if (!(manc & E1000_MANC_RCV_TCO_EN) || + !(manc & E1000_MANC_EN_MAC_ADDR_FILTER)) + return FALSE; + if ((manc & E1000_MANC_SMBUS_EN) && !(manc & E1000_MANC_ASF_EN)) + return TRUE; + } + return FALSE; +} diff -Nuarp --- A/drivers/net/e1000/e1000_hw.h +++ B/drivers/net/e1000/e1000_hw.h @@ -307,6 +307,7 @@ int32_t e1000_led_off(struct e1000_hw *h /* Adaptive IFS Functions */ /* Everything else */ +uint32_t e1000_enable_mng_pass_thru(struct e1000_hw *hw); void e1000_clear_hw_cntrs(struct e1000_hw *hw); void e1000_reset_adaptive(struct e1000_hw *hw); void e1000_update_adaptive(struct e1000_hw *hw); @@ -983,6 +984,7 @@ struct e1000_hw { e1000_ms_type master_slave; e1000_ms_type original_master_slave; e1000_ffe_config ffe_config_state; + uint32_t asf_firmware_present; unsigned long io_base; uint32_t phy_id; uint32_t phy_revision; diff -Nuarp --- A/drivers/net/e1000/e1000_main.c +++ B/drivers/net/e1000/e1000_main.c @@ -299,7 +299,7 @@ e1000_down(struct e1000_adapter *adapter void e1000_reset(struct e1000_adapter *adapter) { - uint32_t pba; + uint32_t pba, manc; /* Repartition Pba for greater than 9k mtu * To take effect CTRL.RST is required. */ @@ -341,6 +341,12 @@ 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); + } } /** @@ -483,6 +489,8 @@ 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 brazilnut@us.ibm.com Thu Jun 17 14:25:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 14:25:37 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HLPXgi016017 for ; Thu, 17 Jun 2004 14:25:33 -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.2) with ESMTP id i5HLPLkw379826; Thu, 17 Jun 2004 17:25:22 -0400 Received: from DYN318364BLD.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 i5HLQ6ku053698; Thu, 17 Jun 2004 17:26:07 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5HLLnt06615; Thu, 17 Jun 2004 14:21:49 -0700 Date: Thu, 17 Jun 2004 14:21:48 -0700 From: Don Fry To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Subject: [PATCH 3 2.6.7] pcnet32: cleanup IRQ limitation. Message-ID: <20040617142148.A6607@DYN318364BLD.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 6082 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: 3392 Lines: 97 Cleanup pcnet32 IRQ handling based on suggestions from Ralf Baechle , and Brian Murphy Tested by myself and Brian Murphy. Please also apply to 2.4.27-pre6. Signed-off-by: Don Fry --- linux-2.6.7/drivers/net/hung.pcnet32.c Wed Jun 16 10:31:44 2004 +++ linux-2.6.7/drivers/net/pcnet32.c Thu Jun 17 13:14:53 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30e" -#define DRV_RELDATE "06.11.2004" +#define DRV_VERSION "1.30f" +#define DRV_RELDATE "06.16.2004" #define PFX DRV_NAME ": " static const char *version = @@ -247,6 +247,9 @@ static int full_duplex[MAX_UNITS]; * v1.30c 25 May 2004 Don Fry added netif_wake_queue after pcnet32_restart. * v1.30d 01 Jun 2004 Don Fry discard oversize rx packets. * v1.30e 11 Jun 2004 Don Fry recover after fifo error and rx hang. + * v1.30f 16 Jun 2004 Don Fry cleanup IRQ to allow 0 and 1 for PCI, + * expanding on suggestions from Ralf Baechle , + * and Brian Murphy . */ @@ -362,7 +365,7 @@ struct pcnet32_private { static void pcnet32_probe_vlbus(void); static int pcnet32_probe_pci(struct pci_dev *, const struct pci_device_id *); -static int pcnet32_probe1(unsigned long, unsigned int, int, struct pci_dev *); +static int pcnet32_probe1(unsigned long, int, struct pci_dev *); static int pcnet32_open(struct net_device *); static int pcnet32_init_ring(struct net_device *); static int pcnet32_start_xmit(struct sk_buff *, struct net_device *); @@ -960,7 +963,7 @@ pcnet32_probe_vlbus(void) if (request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_vlbus")) { /* check if there is really a pcnet chip on that ioaddr */ if ((inb(ioaddr + 14) == 0x57) && (inb(ioaddr + 15) == 0x57)) { - pcnet32_probe1(ioaddr, 0, 0, NULL); + pcnet32_probe1(ioaddr, 0, NULL); } else { release_region(ioaddr, PCNET32_TOTAL_SIZE); } @@ -1001,7 +1004,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, return -EBUSY; } - return pcnet32_probe1(ioaddr, pdev->irq, 1, pdev); + return pcnet32_probe1(ioaddr, 1, pdev); } @@ -1010,8 +1013,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, * pdev will be NULL when called from pcnet32_probe_vlbus. */ static int __devinit -pcnet32_probe1(unsigned long ioaddr, unsigned int irq_line, int shared, - struct pci_dev *pdev) +pcnet32_probe1(unsigned long ioaddr, int shared, struct pci_dev *pdev) { struct pcnet32_private *lp; dma_addr_t lp_dma_addr; @@ -1272,11 +1274,8 @@ pcnet32_probe1(unsigned long ioaddr, uns a->write_csr(ioaddr, 2, (lp->dma_addr + offsetof(struct pcnet32_private, init_block)) >> 16); - if (irq_line) { - dev->irq = irq_line; - } - - if (dev->irq >= 2) { + if (pdev) { /* use the IRQ provided by PCI */ + dev->irq = pdev->irq; if (pcnet32_debug & NETIF_MSG_PROBE) printk(" assigned IRQ %d.\n", dev->irq); } else { @@ -1364,8 +1363,7 @@ pcnet32_open(struct net_device *dev) int rc; unsigned long flags; - if (dev->irq == 0 || - request_irq(dev->irq, &pcnet32_interrupt, + if (request_irq(dev->irq, &pcnet32_interrupt, lp->shared_irq ? SA_SHIRQ : 0, dev->name, (void *)dev)) { return -EAGAIN; } -- Don Fry brazilnut@us.ibm.com From herbert@gondor.apana.org.au Thu Jun 17 14:30:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 14:30:07 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HLU0gi016431 for ; Thu, 17 Jun 2004 14:30: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 1Bb4Rf-0002CA-00; Fri, 18 Jun 2004 07:29:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bb4RZ-0003fb-00; Fri, 18 Jun 2004 07:29:09 +1000 Date: Fri, 18 Jun 2004 07:29:09 +1000 To: Alexey Kuznetsov Cc: "David S. Miller" , schwab@suse.de, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1 Message-ID: <20040617212909.GA14089@gondor.apana.org.au> References: <20040616193731.GB29781@ms2.inr.ac.ru> <20040616130950.6aadde3c.davem@redhat.com> <20040616203748.GA30675@ms2.inr.ac.ru> <20040616134711.499209c9.davem@redhat.com> <20040617081722.GA8559@gondor.apana.org.au> <20040617083303.GA8810@gondor.apana.org.au> <20040617101016.44512cb1.davem@redhat.com> <20040617172449.GA10303@ms2.inr.ac.ru> <20040617105324.554c631b.davem@redhat.com> <20040617190739.GB10925@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617190739.GB10925@ms2.inr.ac.ru> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6083 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: 666 Lines: 19 On Thu, Jun 17, 2004 at 11:07:39PM +0400, Alexey Kuznetsov wrote: > > > and that we need to > > add another call in unregister_netdevice() right before final dev_put(). > > This should be enough. It is enough for this dst case, but it may not be enough in general. Other event handlers may need a rebroadcast before they drop the dev reference. So we really should do the synchronize_net() before freeing the device in net_run_todo(). 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 Jun 17 14:32:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 14:32:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HLWCgi016814 for ; Thu, 17 Jun 2004 14:32: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 1Bb4Tr-0002D2-00; Fri, 18 Jun 2004 07:31:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bb4Tq-0003gR-00; Fri, 18 Jun 2004 07:31:30 +1000 Date: Fri, 18 Jun 2004 07:31:30 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040617213130.GB14089@gondor.apana.org.au> References: <20040616202341.GD29781@ms2.inr.ac.ru> <20040617105843.314dfe30.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617105843.314dfe30.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6084 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: 697 Lines: 18 On Thu, Jun 17, 2004 at 10:58:43AM -0700, David S. Miller wrote: > > Do you see what xfrm_get_mss() does? It calls into x->type->get_max_size() > and this is where ESP reports this kind of thing (re: block padding). Yes I know. But this is only used in TCP currently. It is also rather expensive so you'd really want to cache the results rather than calling it for every packet. For example, xfrm4_check_tunnel_size() needs to use the value from xfrm_get_mss() but isn't. 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 Jun 17 14:39:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 14:39:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HLdJgi017253 for ; Thu, 17 Jun 2004 14:39: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 1Bb4ak-0002G5-00; Fri, 18 Jun 2004 07:38:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bb4ae-0003hF-00; Fri, 18 Jun 2004 07:38:32 +1000 Date: Fri, 18 Jun 2004 07:38:32 +1000 To: Alexey Kuznetsov Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040617213832.GC14089@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617190158.GA10925@ms2.inr.ac.ru> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6085 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: 1917 Lines: 45 On Thu, Jun 17, 2004 at 11:01:58PM +0400, Alexey Kuznetsov wrote: > > > But this is wrong because it assigns > > a single MTU to all hosts behind an IPsec gateway, even though their > > paths may well diverge beyond the gateway. > > Diverge where exactly? On path where packets are transformed? PMTU discovery > cannot do something clever for this case: we receive only small piece > of transformed datagram, in the best case with SPI in it, so we > can only update pmtu not even on bundle, but on even wider aggregate, > on SA itself. This part is missing now, by the way, it is to be done > inside error handlers in transformations. Let's go for an exampe: We have an IPsec tunnel to our default gateway, 0.0.0.0/0[any] 0.0.0.0/0[any] any out ispec esp/tunnel/192.168.0.2-192.168.0.1/ Suppose that the MTU of 192.168.0.1 is 1500, and that the calculated MTU for the bundle is 1430. If there is a host 10.10.10.10 on the Internet or behind some sort a VPN where the path from 192.168.0.1 to it has an MTU of 1200, then by sending a 1430-byte packet to 10.10.10.10 from 192.168.0.2, we will get back an ICMP packet saying that the largest MTU for 192.168.0.2-10.10.10.10 is 1200. This will be successfully stored in the route entry. But the route entry's MTU is not used at all since the MTU of the bundle is deduced from the MTU of the path, 192.168.0.1. So we'll continue to send large packets to 10.10.10.10. > >From another hand, if it is an ICMP from beyond another end of tunnel, > it is problem of original senders to handle them. Gateways even do not > see such ICMPs, which are destined not for them. Agreed. But this falls apart when the gateway is the original sender :) 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 Thu Jun 17 14:54:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 14:54:19 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HLs4gi017868 for ; Thu, 17 Jun 2004 14:54:04 -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 i5HLrSr24658; Thu, 17 Jun 2004 14:53:28 -0700 Date: Thu, 17 Jun 2004 14:53:27 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] convert sk fddi driver to ANSI C Message-Id: <20040617145327.3249f4dc@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: 6086 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: 110908 Lines: 4454 Sparse does not handle K&R at all, and I think I saw Linus saying that he has no intention of adding it to sparse while ago. So here is a blob of patch to convert drivers/net/skfp/* from K&R to ANSI-C. Compile tested with "make allmodconfig" on x86, as I obviously don't have the HW. Mika Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/skfp/cfm.c b/drivers/net/skfp/cfm.c --- a/drivers/net/skfp/cfm.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/cfm.c 2004-06-17 14:49:49 -07:00 @@ -96,14 +96,13 @@ /* * function declarations */ -static void cfm_fsm() ; +static void cfm_fsm(struct s_smc *smc, int cmd); /* init CFM state machine clear all CFM vars and flags */ -void cfm_init(smc) -struct s_smc *smc ; +void cfm_init(struct s_smc *smc) { smc->mib.fddiSMTCF_State = ACTIONS(SC0_ISOLATED) ; smc->r.rm_join = 0 ; @@ -118,9 +117,7 @@ #define THRU_ENABLED(smc) (smc->y[PA].pc_mode != PM_TREE && \ smc->y[PB].pc_mode != PM_TREE) /* Selection criteria for the ports */ -static void selection_criteria (smc,phy) -struct s_smc *smc ; -struct s_phy *phy ; +static void selection_criteria (struct s_smc *smc, struct s_phy *phy) { switch (phy->mib->fddiPORTMy_Type) { @@ -146,8 +143,7 @@ } -void all_selection_criteria (smc) -struct s_smc *smc ; +void all_selection_criteria(struct s_smc *smc) { struct s_phy *phy ; int p ; @@ -158,9 +154,7 @@ } } -static void cem_priv_state (smc, event) -struct s_smc *smc ; -int event ; +static void cem_priv_state(struct s_smc *smc, int event) /* State machine for private PORT states: used to optimize dual homing */ { int np; /* Number of the port */ @@ -216,9 +210,7 @@ process event until SM is stable */ -void cfm(smc,event) -struct s_smc *smc ; -int event ; +void cfm(struct s_smc *smc, int event) { int state ; /* remember last state */ int cond ; @@ -290,9 +282,7 @@ process CFM event */ /*ARGSUSED1*/ -static void cfm_fsm(smc,cmd) -struct s_smc *smc ; -int cmd ; +static void cfm_fsm(struct s_smc *smc, int cmd) { switch(smc->mib.fddiSMTCF_State) { case ACTIONS(SC0_ISOLATED) : @@ -550,8 +540,7 @@ * return : * PA or PB */ -int cfm_get_mac_input(smc) -struct s_smc *smc ; +int cfm_get_mac_input(struct s_smc *smc) { return((smc->mib.fddiSMTCF_State == SC10_C_WRAP_B || smc->mib.fddiSMTCF_State == SC5_THRU_B) ? PB : PA) ; @@ -562,8 +551,7 @@ * return : * PA or PB */ -int cfm_get_mac_output(smc) -struct s_smc *smc ; +int cfm_get_mac_output(struct s_smc *smc) { return((smc->mib.fddiSMTCF_State == SC10_C_WRAP_B || smc->mib.fddiSMTCF_State == SC4_THRU_A) ? PB : PA) ; @@ -603,10 +591,7 @@ 0,0, 0,RES_MAC, 0,INDEX_MAC, 0,PATH_ISO, } ; -int cem_build_path(smc,to,path_index) -struct s_smc *smc ; -char *to ; -int path_index ; +int cem_build_path(struct s_smc *smc, char *to, int path_index) { char *path ; int len ; diff -Nru a/drivers/net/skfp/drvfbi.c b/drivers/net/skfp/drvfbi.c --- a/drivers/net/skfp/drvfbi.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/drvfbi.c 2004-06-17 14:49:49 -07:00 @@ -100,14 +100,13 @@ #endif /* MULT_OEM */ /* Prototypes of external functions */ -extern void hwt_restart() ; #ifdef AIX extern int AIX_vpdReadByte() ; #endif /* Prototypes of local functions. */ -void smt_stop_watchdog() ; +void smt_stop_watchdog(struct s_smc *smc); #ifdef MCA static int read_card_id() ; @@ -129,8 +128,7 @@ /* * FDDI card reset */ -static void card_start(smc) -struct s_smc *smc ; +static void card_start(struct s_smc *smc) { int i ; #ifdef PCI @@ -250,8 +248,7 @@ GET_PAGE(0) ; /* necessary for BOOT */ } -void card_stop(smc) -struct s_smc *smc ; +void card_stop(struct s_smc *smc) { smt_stop_watchdog(smc) ; smc->hw.mac_ring_is_up = 0 ; /* ring down */ @@ -282,14 +279,11 @@ } /*--------------------------- ISR handling ----------------------------------*/ -#ifndef PCI -void mac1_irq(smc,stu, stl) -struct s_smc *smc ; -u_short stu; -u_short stl; +void mac1_irq(struct s_smc *smc, u_short stu, u_short stl) { int restart_tx = 0 ; again: +#ifndef PCI #ifndef ISA /* * FORMAC+ bug modified the queue pointer if many read/write accesses happens!? @@ -344,14 +338,6 @@ } #else /* PCI */ -void mac1_irq(smc,stu, stl) -struct s_smc *smc ; -u_short stu; -u_short stl; -{ - int restart_tx = 0 ; -again: - /* * parity error: note encoding error is not possible in tag mode */ @@ -396,8 +382,7 @@ * interrupt source= plc1 * this function is called in nwfbisr.asm */ -void plc1_irq(smc) -struct s_smc *smc ; +void plc1_irq(struct s_smc *smc) { u_short st = inpw(PLC(PB,PL_INTR_EVENT)) ; @@ -412,8 +397,7 @@ * interrupt source= plc2 * this function is called in nwfbisr.asm */ -void plc2_irq(smc) -struct s_smc *smc ; +void plc2_irq(struct s_smc *smc) { u_short st = inpw(PLC(PA,PL_INTR_EVENT)) ; @@ -428,8 +412,7 @@ /* * interrupt source= timer */ -void timer_irq(smc) -struct s_smc *smc ; +void timer_irq(struct s_smc *smc) { hwt_restart(smc); smc->hw.t_stop = smc->hw.t_start; @@ -439,8 +422,7 @@ /* * return S-port (PA or PB) */ -int pcm_get_s_port(smc) -struct s_smc *smc ; +int pcm_get_s_port(struct s_smc *smc) { SK_UNUSED(smc) ; return(PS) ; @@ -457,9 +439,7 @@ #define STATION_LABEL_PMD_OFFSET 6 #define STATION_LABEL_PORT_OFFSET 7 -void read_address(smc,mac_addr) -struct s_smc *smc ; -u_char *mac_addr ; +void read_address(struct s_smc *smc, u_char *mac_addr) { char ConnectorType ; char PmdType ; @@ -528,9 +508,7 @@ /* * FDDI card soft reset */ -void init_board(smc,mac_addr) -struct s_smc *smc ; -u_char *mac_addr ; +void init_board(struct s_smc *smc, u_char *mac_addr) { card_start(smc) ; read_address(smc,mac_addr) ; @@ -559,9 +537,7 @@ /* * insert or deinsert optical bypass (called by ECM) */ -void sm_pm_bypass_req(smc,mode) -struct s_smc *smc ; -int mode; +void sm_pm_bypass_req(struct s_smc *smc, int mode) { #if (defined(ISA) || defined(EISA)) int csra_v ; @@ -614,8 +590,7 @@ /* * check if bypass connected */ -int sm_pm_bypass_present(smc) -struct s_smc *smc ; +int sm_pm_bypass_present(struct s_smc *smc) { #ifndef PCI return( (inpw(CSR_A) & CS_BYSTAT) ? FALSE : TRUE ) ; @@ -624,9 +599,7 @@ #endif } -void plc_clear_irq(smc,p) -struct s_smc *smc ; -int p ; +void plc_clear_irq(struct s_smc *smc, int p) { SK_UNUSED(p) ; @@ -658,9 +631,7 @@ * LED_Y_OFF just switch yellow LED off * LED_Y_ON just switch yello LED on */ -void led_indication(smc,led_event) -struct s_smc *smc ; -int led_event; +void led_indication(struct s_smc *smc, int led_event) { /* use smc->hw.mac_ring_is_up == TRUE * as indication for Ring Operational @@ -754,10 +725,7 @@ } -void pcm_state_change(smc,plc,p_state) -struct s_smc *smc; -int plc; -int p_state; +void pcm_state_change(struct s_smc *smc, int plc, int p_state) { /* * the current implementation of pcm_state_change() in the driver @@ -770,9 +738,7 @@ } -void rmt_indication(smc,i) -struct s_smc *smc ; -int i; +void rmt_indication(struct s_smc *smc, int i) { /* Call a driver special function if defined */ DRV_RMT_INDICATION(smc,i) ; @@ -784,8 +750,7 @@ /* * llc_recover_tx called by init_tx (fplus.c) */ -void llc_recover_tx(smc) -struct s_smc *smc ; +void llc_recover_tx(struct s_smc *smc) { #ifdef LOAD_GEN extern int load_gen_flag ; @@ -805,9 +770,7 @@ /* * init DMA */ -void init_dma(smc,dma) -struct s_smc *smc; -int dma; +void init_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; @@ -828,9 +791,7 @@ /* * disable DMA */ -void dis_dma(smc,dma) -struct s_smc *smc ; -int dma; +void dis_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; @@ -854,9 +815,7 @@ static const int base[8] = { 0x000,0x002,0x004,0x006,0,0x0c4,0x0c8,0x0cc } ; static const int page[8] = { 0x087,0x083,0x081,0x082,0,0x08b,0x089,0x08a } ; -void init_dma(smc,dma) -struct s_smc *smc ; -int dma; +void init_dma(struct s_smc *smc, int dma) { /* * extended mode register @@ -885,9 +844,7 @@ } -void dis_dma(smc,dma) -struct s_smc *smc ; -int dma; +void dis_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; @@ -896,16 +853,13 @@ #endif /* EISA */ #ifdef MCA -void init_dma(smc,dma) -struct s_smc *smc; -int dma; +void init_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; SK_UNUSED(dma) ; } -void dis_dma(smc,dma) -struct s_smc *smc; -int dma; + +void dis_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; SK_UNUSED(dma) ; @@ -913,16 +867,13 @@ #endif #ifdef PCI -void init_dma(smc,dma) -struct s_smc *smc; -int dma; +void init_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; SK_UNUSED(dma) ; } -void dis_dma(smc,dma) -struct s_smc *smc; -int dma; + +void dis_dma(struct s_smc *smc, int dma) { SK_UNUSED(smc) ; SK_UNUSED(dma) ; @@ -930,10 +881,7 @@ #endif #ifdef MULT_OEM -static int is_equal_num(comp1,comp2,num) -char comp1[] ; -char comp2[] ; -int num ; +static int is_equal_num(char comp1[], char comp2[], int num) { int i ; @@ -954,8 +902,7 @@ * 2 data base empty * 3 no active entry */ -int set_oi_id_def(smc) -struct s_smc *smc ; +int set_oi_id_def(struct s_smc *smc) { int sel_id ; int i ; @@ -1029,9 +976,7 @@ * ************************/ #define LONG_CARD_ID(lo, hi) ((((hi) & 0xff) << 8) | ((lo) & 0xff)) -int exist_board(smc,slot) -struct s_smc *smc ; -int slot ; +int exist_board(struct s_smc *smc, int slot) { #ifdef MULT_OEM SK_LOC_DECL(u_char,id[2]) ; @@ -1081,9 +1026,8 @@ * number is specified, the function returns zero. * ************************/ -static int read_card_id(smc,slot) -struct s_smc *smc ; /* Do not use. */ -int slot ; +static int read_card_id(struct s_smc *smc, int slot) +/* struct s_smc *smc ; Do not use. */ { int card_id ; @@ -1126,9 +1070,7 @@ * END_MANUAL_ENTRY() * ************************/ -int get_board_para(smc,slot) -struct s_smc *smc ; -int slot ; +int get_board_para(struct s_smc *smc, int slot) { int val ; int i ; @@ -1175,9 +1117,7 @@ } /* Enable access to specified MCA slot. */ -static void EnableSlotAccess(smc,slot) -struct s_smc *smc ; -int slot ; +static void EnableSlotAccess(struct s_smc *smc, int slot) { SK_UNUSED(slot) ; @@ -1195,8 +1135,7 @@ } /* Disable access to MCA slot formerly enabled via EnableSlotAccess(). */ -static void DisableSlotAccess(smc) -struct s_smc *smc ; +static void DisableSlotAccess(struct s_smc *smc) { #ifndef AIX SK_UNUSED(smc) ; @@ -1245,9 +1184,7 @@ * The smc pointer must be valid now. * ************************/ -int exist_board(smc,slot) -struct s_smc *smc ; -int slot ; +int exist_board(struct s_smc *smc, int slot) { int i ; #ifdef MULT_OEM @@ -1284,9 +1221,7 @@ } -int get_board_para(smc,slot) -struct s_smc *smc ; -int slot ; +int get_board_para(struct s_smc *smc, int slot) { int i ; @@ -1327,9 +1262,7 @@ #endif /* MULT_OEM */ -int exist_board(smc,port) -struct s_smc *smc ; -HW_PTR port ; +int exist_board(struct s_smc *smc, HW_PTR port) { int i ; #ifdef MULT_OEM @@ -1400,9 +1333,7 @@ #endif /* MULT_OEM */ } -int get_board_para(smc,slot) -struct s_smc *smc ; -int slot ; +int get_board_para(struct s_smc *smc, int slot) { SK_UNUSED(smc) ; SK_UNUSED(slot) ; @@ -1412,9 +1343,7 @@ #ifdef PCI #ifdef USE_BIOS_FUN -int exist_board(smc,slot) -struct s_smc *smc ; -int slot ; +int exist_board(struct s_smc *smc, int slot) { u_short dev_id ; u_short ven_id ; @@ -1452,9 +1381,7 @@ #endif /* PCI */ #endif /* USE_BIOS_FUNC */ -void driver_get_bia(smc, bia_addr) -struct s_smc *smc ; -struct fddi_addr *bia_addr ; +void driver_get_bia(struct s_smc *smc, struct fddi_addr *bia_addr) { int i ; @@ -1465,8 +1392,7 @@ } } -void smt_start_watchdog(smc) -struct s_smc *smc ; +void smt_start_watchdog(struct s_smc *smc) { SK_UNUSED(smc) ; /* Make LINT happy. */ @@ -1481,8 +1407,7 @@ #endif /* DEBUG */ } -void smt_stop_watchdog(smc) -struct s_smc *smc ; +void smt_stop_watchdog(struct s_smc *smc) { SK_UNUSED(smc) ; /* Make LINT happy. */ #ifndef DEBUG @@ -1497,9 +1422,7 @@ } #ifdef PCI -static char get_rom_byte(smc,addr) -struct s_smc *smc ; -u_short addr ; +static char get_rom_byte(struct s_smc *smc, u_short addr) { GET_PAGE(addr) ; return (READ_PROM(ADDR(B2_FDP))) ; @@ -1544,11 +1467,7 @@ * * END_MANUAL_ENTRY */ -int mac_drv_vpd_read(smc,buf,size,image) -struct s_smc *smc ; -char *buf ; -int size ; -char image ; +int mac_drv_vpd_read(struct s_smc *smc, char *buf, int size, char image) { u_short ibase ; u_short pci_base ; @@ -1597,16 +1516,14 @@ return(len) ; } -void mac_drv_pci_fix(smc,fix_value) -struct s_smc *smc ; -u_long fix_value ; +void mac_drv_pci_fix(struct s_smc *smc, u_long fix_value) { smc->hw.pci_fix_value = fix_value ; } -void mac_do_pci_fix(smc) -struct s_smc *smc ; +void mac_do_pci_fix(struct s_smc *smc) { SK_UNUSED(smc) ; } #endif /* PCI */ + diff -Nru a/drivers/net/skfp/ecm.c b/drivers/net/skfp/ecm.c --- a/drivers/net/skfp/ecm.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/ecm.c 2004-06-17 14:49:49 -07:00 @@ -94,17 +94,16 @@ * function declarations */ -static void ecm_fsm() ; -static void start_ecm_timer() ; -static void stop_ecm_timer() ; -static void prop_actions() ; +static void ecm_fsm(struct s_smc *smc, int cmd); +static void start_ecm_timer(struct s_smc *smc, u_long value, int event); +static void stop_ecm_timer(struct s_smc *smc); +static void prop_actions(struct s_smc *smc); /* init ECM state machine clear all ECM vars and flags */ -void ecm_init(smc) -struct s_smc *smc ; +void ecm_init(struct s_smc *smc) { smc->e.path_test = PT_PASSED ; smc->e.trace_prop = 0 ; @@ -122,9 +121,7 @@ process event until SM is stable */ -void ecm(smc,event) -struct s_smc *smc ; -int event ; +void ecm(struct s_smc *smc, int event) { int state ; @@ -143,9 +140,7 @@ /* process ECM event */ -static void ecm_fsm(smc,cmd) -struct s_smc *smc ; -int cmd ; +static void ecm_fsm(struct s_smc *smc, int cmd) { int ls_a ; /* current line state PHY A */ int ls_b ; /* current line state PHY B */ @@ -429,8 +424,7 @@ /* * trace propagation actions for SAS & DAS */ -static void prop_actions(smc) -struct s_smc *smc ; +static void prop_actions(struct s_smc *smc) { int port_in = 0 ; int port_out = 0 ; @@ -480,8 +474,7 @@ /* * trace propagation actions for Concentrator */ -static void prop_actions(smc) -struct s_smc *smc ; +static void prop_actions(struct s_smc *smc) { int initiator ; int upstream ; @@ -527,10 +520,7 @@ * SMT timer interface * start ECM timer */ -static void start_ecm_timer(smc,value,event) -struct s_smc *smc ; -u_long value; -int event ; +static void start_ecm_timer(struct s_smc *smc, u_long value, int event) { smt_timer_start(smc,&smc->e.ecm_timer,value,EV_TOKEN(EVENT_ECM,event)); } @@ -539,8 +529,7 @@ * SMT timer interface * stop ECM timer */ -static void stop_ecm_timer(smc) -struct s_smc *smc ; +static void stop_ecm_timer(struct s_smc *smc) { if (smc->e.ecm_timer.tm_active) smt_timer_stop(smc,&smc->e.ecm_timer) ; diff -Nru a/drivers/net/skfp/ess.c b/drivers/net/skfp/ess.c --- a/drivers/net/skfp/ess.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/ess.c 2004-06-17 14:49:49 -07:00 @@ -80,8 +80,11 @@ ------------------------------------------------------------- */ -static void ess_send_response(), ess_config_fifo(), - ess_send_alc_req(), ess_send_frame() ; +static void ess_send_response(struct s_smc *smc, struct smt_header *sm, + int sba_cmd); +static void ess_config_fifo(struct s_smc *smc); +static void ess_send_alc_req(struct s_smc *smc); +static void ess_send_frame(struct s_smc *smc, SMbuf *mb); /* ------------------------------------------------------------- @@ -89,26 +92,17 @@ ------------------------------------------------------------- */ -extern void *sm_to_para() ; - -extern void smt_send_frame(), smt_free_mbuf(), - set_formac_tsync(), formac_reinit_tx() ; - -extern int smt_check_para() ; - -extern SMbuf *smt_get_mbuf(), *smt_build_frame() ; - -extern u_long smt_get_tid() ; - /* ------------------------------------------------------------- PUBLIC FUNCTIONS: ------------------------------------------------------------- */ - void ess_timer_poll(), ess_para_change() ; - - int ess_raf_received_pack(), process_bw_alloc() ; +void ess_timer_poll(struct s_smc *smc); +void ess_para_change(struct s_smc *smc); +int ess_raf_received_pack(struct s_smc *smc, SMbuf *mb, struct smt_header *sm, + int fs); +int process_bw_alloc(struct s_smc *smc, long int payload, long int overhead); /* @@ -120,11 +114,8 @@ /* * evaluate the RAF frame */ -int ess_raf_received_pack(smc,mb,sm,fs) -struct s_smc *smc ; -SMbuf *mb ; -struct smt_header *sm ; -int fs ; +int ess_raf_received_pack(struct s_smc *smc, SMbuf *mb, struct smt_header *sm, + int fs) { void *p ; /* universal pointer */ struct smt_p_0016 *cmd ; /* para: command for the ESS */ @@ -384,10 +375,7 @@ * determines the synchronous bandwidth, set the TSYNC register and the * mib variables SBAPayload, SBAOverhead and fddiMACT-NEG. */ -int process_bw_alloc(smc,payload,overhead) -struct s_smc *smc ; -long payload ; -long overhead ; +int process_bw_alloc(struct s_smc *smc, long int payload, long int overhead) { /* * determine the synchronous bandwidth (sync_bw) in bytes per T-NEG, @@ -483,10 +471,8 @@ return(TRUE) ; } -static void ess_send_response(smc,sm,sba_cmd) -struct s_smc *smc ; -struct smt_header *sm ; -int sba_cmd ; +static void ess_send_response(struct s_smc *smc, struct smt_header *sm, + int sba_cmd) { struct smt_sba_chg *chg ; SMbuf *mb ; @@ -550,9 +536,7 @@ ess_send_frame(smc,mb) ; } - -void ess_timer_poll(smc) -struct s_smc *smc ; +void ess_timer_poll(struct s_smc *smc) { if (!smc->ess.raf_act_timer_poll) return ; @@ -566,8 +550,7 @@ } } -static void ess_send_alc_req(smc) -struct s_smc *smc ; +static void ess_send_alc_req(struct s_smc *smc) { struct smt_sba_alc_req *req ; SMbuf *mb ; @@ -675,9 +658,7 @@ ess_send_frame(smc,mb) ; } -static void ess_send_frame(smc,mb) -struct s_smc *smc ; -SMbuf *mb ; +static void ess_send_frame(struct s_smc *smc, SMbuf *mb) { /* * check if the frame must be send to the own ESS @@ -703,15 +684,13 @@ } } -void ess_para_change(smc) -struct s_smc *smc ; +void ess_para_change(struct s_smc *smc) { (void)process_bw_alloc(smc,(long)smc->mib.a[PATH0].fddiPATHSbaPayload, (long)smc->mib.a[PATH0].fddiPATHSbaOverhead) ; } -static void ess_config_fifo(smc) -struct s_smc *smc ; +static void ess_config_fifo(struct s_smc *smc) { /* * if nothing to do exit @@ -738,3 +717,4 @@ #endif /* ESS */ #endif /* no SLIM_SMT */ + diff -Nru a/drivers/net/skfp/fplustm.c b/drivers/net/skfp/fplustm.c --- a/drivers/net/skfp/fplustm.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/fplustm.c 2004-06-17 14:49:49 -07:00 @@ -43,10 +43,10 @@ /* * prototypes for static function */ -static void build_claim_beacon() ; -static int init_mac() ; -static void rtm_init() ; -static void smt_split_up_fifo() ; +static void build_claim_beacon(struct s_smc *smc, u_long t_request); +static int init_mac(struct s_smc *smc, int all); +static void rtm_init(struct s_smc *smc); +static void smt_split_up_fifo(struct s_smc *smc); #if (!defined(NO_SMT_PANIC) || defined(DEBUG)) static char write_mdr_warning [] = "E350 write_mdr() FM_SNPPND is set\n"; @@ -107,8 +107,7 @@ FM_SLOCLM | FM_SHICLM | FM_SMYCLM | FM_SCLM ; -static u_long mac_get_tneg(smc) -struct s_smc *smc ; +static u_long mac_get_tneg(struct s_smc *smc) { u_long tneg ; @@ -117,8 +116,7 @@ 0xffe00000L)) ; } -void mac_update_counter(smc) -struct s_smc *smc ; +void mac_update_counter(struct s_smc *smc) { smc->mib.m[MAC0].fddiMACFrame_Ct = (smc->mib.m[MAC0].fddiMACFrame_Ct & 0xffff0000L) @@ -143,9 +141,7 @@ /* * write long value into buffer memory over memory data register (MDR), */ -void write_mdr(smc,val) -struct s_smc *smc ; -u_long val; +void write_mdr(struct s_smc *smc, u_long val) { CHECK_NPP() ; MDRW(val) ; @@ -154,9 +150,7 @@ /* * read long value from buffer memory over memory data register (MDR), */ -u_long read_mdr(smc,addr) -struct s_smc *smc ; -unsigned int addr; +u_long read_mdr(struct s_smc *smc, unsigned int addr) { long p ; CHECK_NPP() ; @@ -173,8 +167,7 @@ /* * clear buffer memory */ -static void init_ram(smc) -struct s_smc *smc ; +static void init_ram(struct s_smc *smc) { u_short i ; @@ -193,8 +186,7 @@ /* * set receive FIFO pointer */ -static void set_recvptr(smc) -struct s_smc *smc ; +static void set_recvptr(struct s_smc *smc) { /* * initialize the pointer for receive queue 1 @@ -224,8 +216,7 @@ /* * set transmit FIFO pointer */ -static void set_txptr(smc) -struct s_smc *smc ; +static void set_txptr(struct s_smc *smc) { outpw(FM_A(FM_CMDREG2),FM_IRSTQ) ; /* reset transmit queues */ @@ -257,8 +248,7 @@ /* * init memory buffer management registers */ -static void init_rbc(smc) -struct s_smc *smc ; +static void init_rbc(struct s_smc *smc) { u_short rbc_ram_addr ; @@ -279,8 +269,7 @@ /* * init rx pointer */ -static void init_rx(smc) -struct s_smc *smc ; +static void init_rx(struct s_smc *smc) { struct s_smt_rx_queue *queue ; @@ -302,9 +291,7 @@ /* * set the TSYNC register of the FORMAC to regulate synchronous transmission */ -void set_formac_tsync(smc,sync_bw) -struct s_smc *smc ; -long sync_bw ; +void set_formac_tsync(struct s_smc *smc, long sync_bw) { outpw(FM_A(FM_TSYNC),(unsigned int) (((-sync_bw) >> 5) & 0xffff) ) ; } @@ -312,8 +299,7 @@ /* * init all tx data structures */ -static void init_tx(smc) -struct s_smc *smc ; +static void init_tx(struct s_smc *smc) { struct s_smt_tx_queue *queue ; @@ -339,8 +325,7 @@ llc_recover_tx(smc) ; } -static void mac_counter_init(smc) -struct s_smc *smc ; +static void mac_counter_init(struct s_smc *smc) { int i ; u_long *ec ; @@ -363,8 +348,7 @@ /* * set FORMAC address, and t_request */ -static void set_formac_addr(smc) -struct s_smc *smc ; +static void set_formac_addr(struct s_smc *smc) { long t_requ = smc->mib.m[MAC0].fddiMACT_Req ; @@ -390,9 +374,7 @@ outpw(FM_A(FM_TREQ0),(unsigned)t_requ) ; } -static void set_int(p,l) -char *p; -int l; +static void set_int(char *p, int l) { p[0] = (char)(l >> 24) ; p[1] = (char)(l >> 16) ; @@ -408,12 +390,12 @@ * else * append 'end of chain' pointer */ -static void copy_tx_mac(smc,td,mac,off,len) -struct s_smc *smc ; -u_long td; /* transmit descriptor */ -struct fddi_mac *mac; /* mac frame pointer */ -unsigned off; /* start address within buffer memory */ -int len ; /* lenght of the frame including the FC */ +static void copy_tx_mac(struct s_smc *smc, u_long td, struct fddi_mac *mac, + unsigned off, int len) +/* u_long td; transmit descriptor */ +/* struct fddi_mac *mac; mac frame pointer */ +/* unsigned off; start address within buffer memory */ +/* int len ; lenght of the frame including the FC */ { int i ; u_int *p ; @@ -457,8 +439,7 @@ END_MANUAL_ENTRY */ -static void directed_beacon(smc) -struct s_smc *smc ; +static void directed_beacon(struct s_smc *smc) { SK_LOC_DECL(u_int,a[2]) ; @@ -487,9 +468,7 @@ special frame packets end with a pointer to their own descriptor, and the MORE bit is set in the descriptor */ -static void build_claim_beacon(smc,t_request) -struct s_smc *smc ; -u_long t_request; +static void build_claim_beacon(struct s_smc *smc, u_long t_request) { u_int td ; int len ; @@ -550,8 +529,7 @@ outpw(FM_A(FM_RPXSF),0) ; } -void formac_rcv_restart(smc) -struct s_smc *smc ; +void formac_rcv_restart(struct s_smc *smc) { /* enable receive function */ SETMASK(FM_A(FM_MDREG1),smc->hw.fp.rx_mode,FM_ADDRX) ; @@ -559,15 +537,13 @@ outpw(FM_A(FM_CMDREG1),FM_ICLLR) ; /* clear receive lock */ } -void formac_tx_restart(smc) -struct s_smc *smc ; +void formac_tx_restart(struct s_smc *smc) { outpw(FM_A(FM_CMDREG1),FM_ICLLS) ; /* clear s-frame lock */ outpw(FM_A(FM_CMDREG1),FM_ICLLA0) ; /* clear a-frame lock */ } -static void enable_formac(smc) -struct s_smc *smc ; +static void enable_formac(struct s_smc *smc) { /* set formac IMSK : 0 enables irq */ outpw(FM_A(FM_IMSK1U),~mac_imsk1u) ; @@ -607,9 +583,8 @@ END_MANUAL_ENTRY */ -void enable_tx_irq(smc, queue) -struct s_smc *smc ; -u_short queue ; /* 0 = synchronous queue, 1 = asynchronous queue 0 */ +void enable_tx_irq(struct s_smc *smc, u_short queue) +/* u_short queue; 0 = synchronous queue, 1 = asynchronous queue 0 */ { u_short imask ; @@ -643,9 +618,8 @@ END_MANUAL_ENTRY */ -void disable_tx_irq(smc, queue) -struct s_smc *smc ; -u_short queue ; /* 0 = synchronous queue, 1 = asynchronous queue 0 */ +void disable_tx_irq(struct s_smc *smc, u_short queue) +/* u_short queue; 0 = synchronous queue, 1 = asynchronous queue 0 */ { u_short imask ; @@ -660,8 +634,7 @@ } #endif -static void disable_formac(smc) -struct s_smc *smc ; +static void disable_formac(struct s_smc *smc) { /* clear formac IMSK : 1 disables irq */ outpw(FM_A(FM_IMSK1U),MW) ; @@ -673,9 +646,7 @@ } -static void mac_ring_up(smc,up) -struct s_smc *smc ; -int up; +static void mac_ring_up(struct s_smc *smc, int up) { if (up) { formac_rcv_restart(smc) ; /* enable receive function */ @@ -702,10 +673,7 @@ * mac2_irq: status bits for the receive queue 1, and ring status * ring status indication bits */ -void mac2_irq(smc,code_s2u,code_s2l) -struct s_smc *smc ; -u_short code_s2u ; -u_short code_s2l ; +void mac2_irq(struct s_smc *smc, u_short code_s2u, u_short code_s2l) { u_short change_s2l ; u_short change_s2u ; @@ -831,10 +799,7 @@ /* * mac3_irq: receive queue 2 bits and address detection bits */ -void mac3_irq(smc,code_s3u,code_s3l) -struct s_smc *smc ; -u_short code_s3u ; -u_short code_s3l ; +void mac3_irq(struct s_smc *smc, u_short code_s3u, u_short code_s3l) { UNUSED(code_s3l) ; @@ -857,8 +822,7 @@ /* * take formac offline */ -static void formac_offline(smc) -struct s_smc *smc ; +static void formac_offline(struct s_smc *smc) { outpw(FM_A(FM_CMDREG2),FM_IACTR) ;/* abort current transmit activity */ @@ -876,8 +840,7 @@ /* * bring formac online */ -static void formac_online(smc) -struct s_smc *smc ; +static void formac_online(struct s_smc *smc) { enable_formac(smc) ; SETMASK(FM_A(FM_MDREG1),FM_MONLINE | FM_SELRA | MDR1INIT | @@ -887,8 +850,7 @@ /* * FORMAC+ full init. (tx, rx, timer, counter, claim & beacon) */ -int init_fplus(smc) -struct s_smc *smc ; +int init_fplus(struct s_smc *smc) { smc->hw.fp.nsa_mode = FM_MRNNSAFNMA ; smc->hw.fp.rx_mode = FM_MDAMA ; @@ -926,9 +888,7 @@ /* enable_formac(smc) ; */ } -static int init_mac(smc,all) -struct s_smc *smc ; -int all ; +static int init_mac(struct s_smc *smc, int all) { u_short t_max,x ; u_long time=0 ; @@ -1033,9 +993,7 @@ /* * called by CFM */ -void config_mux(smc,mux) -struct s_smc *smc ; -int mux; +void config_mux(struct s_smc *smc, int mux) { plc_config_mux(smc,mux) ; @@ -1049,8 +1007,7 @@ * the interrupt must not be permanently enabled * RMT calls this function periodically (timer driven polling) */ -void sm_mac_check_beacon_claim(smc) -struct s_smc *smc ; +void sm_mac_check_beacon_claim(struct s_smc *smc) { /* set formac IMSK : 0 enables irq */ outpw(FM_A(FM_IMSK2U),~(mac_imsk2u | mac_beacon_imsk2u)) ; @@ -1063,9 +1020,7 @@ /* * control ODL output */ -void sm_pm_control(smc,mode) -struct s_smc *smc ; -int mode; +void sm_pm_control(struct s_smc *smc, int mode) { SK_UNUSED(smc) ; @@ -1084,9 +1039,7 @@ /* * control MAC layer (called by RMT) */ -void sm_ma_control(smc,mode) -struct s_smc *smc ; -int mode; +void sm_ma_control(struct s_smc *smc, int mode) { switch(mode) { case MA_OFFLINE : @@ -1110,8 +1063,7 @@ } } -int sm_mac_get_tx_state(smc) -struct s_smc *smc ; +int sm_mac_get_tx_state(struct s_smc *smc) { return((inpw(FM_A(FM_STMCHN))>>4)&7) ; } @@ -1120,12 +1072,10 @@ * multicast functions */ -static struct s_fpmc *mac_get_mc_table(smc,user,own,del,can) -struct s_smc *smc ; -struct fddi_addr *user ; -struct fddi_addr *own ; -int del ; -int can ; +static struct s_fpmc* mac_get_mc_table(struct s_smc *smc, + struct fddi_addr *user, + struct fddi_addr *own, + int del, int can) { struct s_fpmc *tb ; struct s_fpmc *slot ; @@ -1166,8 +1116,7 @@ END_MANUAL_ENTRY() */ -void mac_clear_multicast(smc) -struct s_smc *smc ; +void mac_clear_multicast(struct s_smc *smc) { struct s_fpmc *tb ; int i ; @@ -1198,9 +1147,7 @@ END_MANUAL_ENTRY() */ -int mac_set_func_addr(smc,f_addr) -struct s_smc *smc ; -u_long f_addr ; +int mac_set_func_addr(struct s_smc *smc, u_long f_addr) { smc->hw.fp.func_addr = f_addr ; return(0) ; @@ -1235,10 +1182,7 @@ END_MANUAL_ENTRY() */ -int mac_add_multicast(smc,addr,can) -struct s_smc *smc ; -struct fddi_addr *addr ; -int can ; +int mac_add_multicast(struct s_smc *smc, struct fddi_addr *addr, int can) { SK_LOC_DECL(struct fddi_addr,own) ; struct s_fpmc *tb ; @@ -1292,10 +1236,7 @@ END_MANUAL_ENTRY() */ -void mac_del_multicast(smc,addr,can) -struct s_smc *smc ; -struct fddi_addr *addr ; -int can ; +void mac_del_multicast(struct s_smc *smc, struct fddi_addr *addr, int can) { SK_LOC_DECL(struct fddi_addr,own) ; struct s_fpmc *tb ; @@ -1341,8 +1282,7 @@ END_MANUAL_ENTRY() */ -void mac_update_multicast(smc) -struct s_smc *smc ; +void mac_update_multicast(struct s_smc *smc) { struct s_fpmc *tb ; u_char *fu ; @@ -1418,9 +1358,7 @@ END_MANUAL_ENTRY */ -void mac_set_rx_mode(smc,mode) -struct s_smc *smc ; -int mode ; +void mac_set_rx_mode(struct s_smc *smc, int mode) { switch (mode) { case RX_ENABLE_ALLMULTI : @@ -1476,8 +1414,7 @@ END_MANUAL_ENTRY */ -void rtm_irq(smc) -struct s_smc *smc ; +void rtm_irq(struct s_smc *smc) { outpw(ADDR(B2_RTM_CRTL),TIM_CL_IRQ) ; /* clear IRQ */ if (inpw(ADDR(B2_RTM_CRTL)) & TIM_RES_TOK) { @@ -1490,15 +1427,13 @@ outpw(ADDR(B2_RTM_CRTL),TIM_START) ; /* enable RTM monitoring */ } -static void rtm_init(smc) -struct s_smc *smc ; +static void rtm_init(struct s_smc *smc) { outpd(ADDR(B2_RTM_INI),0) ; /* timer = 0 */ outpw(ADDR(B2_RTM_CRTL),TIM_START) ; /* enable IRQ */ } -void rtm_set_timer(smc) -struct s_smc *smc ; +void rtm_set_timer(struct s_smc *smc) { /* * MIB timer and hardware timer have the same resolution of 80nS @@ -1508,8 +1443,7 @@ outpd(ADDR(B2_RTM_INI),smc->mib.a[PATH0].fddiPATHT_Rmode) ; } -static void smt_split_up_fifo(smc) -struct s_smc *smc ; +static void smt_split_up_fifo(struct s_smc *smc) { /* @@ -1629,8 +1563,7 @@ smc->hw.fp.fifo.tx_a0_start, smc->hw.fp.fifo.rx2_fifo_start) ; } -void formac_reinit_tx(smc) -struct s_smc *smc ; +void formac_reinit_tx(struct s_smc *smc) { /* * Split up the FIFO and reinitialize the MAC if synchronous @@ -1641,5 +1574,4 @@ (void)init_mac(smc,0) ; } } - diff -Nru a/drivers/net/skfp/h/cmtdef.h b/drivers/net/skfp/h/cmtdef.h --- a/drivers/net/skfp/h/cmtdef.h 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/h/cmtdef.h 2004-06-17 14:49:49 -07:00 @@ -418,7 +418,6 @@ void *pc_p ; } ; - /* * link error monitor */ @@ -444,7 +443,6 @@ #define NUMBITS 10 - #ifdef AMDPLC /* @@ -480,216 +478,184 @@ * function prototypes */ #include "h/mbuf.h" /* Type definitions for MBUFs */ -void hwt_restart( /* hwt.c */ -#ifdef ANSIC - struct s_smc *smc -#endif - ) ; - -SMbuf *smt_build_frame( /* smt.c */ -#ifdef ANSIC - struct s_smc *smc, - int class, - int type, - int length -#endif - ) ; - -SMbuf *smt_get_mbuf( /* drvsr.c */ -#ifdef ANSIC - struct s_smc *smc -#endif - ) ; - -void *sm_to_para( /* smt.c */ -#ifdef ANSIC - struct s_smc *smc, - struct smt_header *sm, - int para -#endif - ) ; +#include "h/smtstate.h" /* struct smt_state */ + +void hwt_restart(struct s_smc *smc); /* hwt.c */ +SMbuf *smt_build_frame(struct s_smc *smc, int class, int type, + int length); /* smt.c */ +SMbuf *smt_get_mbuf(struct s_smc *smc); /* drvsr.c */ +void *sm_to_para(struct s_smc *smc, struct smt_header *sm, + int para); /* smt.c */ #ifndef SK_UNUSED #define SK_UNUSED(var) (void)(var) #endif -void queue_event() ; -void ecm() ; -void ecm_init() ; -void rmt() ; -void rmt_init() ; -void pcm() ; -void pcm_init() ; -void cfm() ; -void cfm_init() ; -void smt_timer_start() ; -void smt_timer_stop() ; -void pcm_status_state() ; -void plc_config_mux() ; -void sm_lem_evaluate() ; -void smt_clear_una_dna() ; -void mac_status_para() ; -void mac_update_counter() ; -void sm_pm_ls_latch() ; -void sm_ma_control() ; -void sm_mac_check_beacon_claim() ; -void config_mux() ; -void smt_agent_init() ; -void smt_timer_init() ; -void smt_received_pack() ; -void smt_add_para() ; -void smt_swap_para() ; -void ev_init() ; -void hwt_init() ; -u_long hwt_read() ; -void hwt_stop() ; -void hwt_start() ; -void smt_send_mbuf() ; -void smt_free_mbuf() ; -void sm_pm_bypass_req() ; -void rmt_indication() ; -void cfm_state_change() ; -void rx_indication() ; -void tx_indication() ; -#ifndef NO_SMT_PANIC -void smt_panic() ; -#else -#ifdef DEBUG -void smt_panic() ; +void queue_event(struct s_smc *smc, int class, int event); +void ecm(struct s_smc *smc, int event); +void ecm_init(struct s_smc *smc); +void rmt(struct s_smc *smc, int event); +void rmt_init(struct s_smc *smc); +void pcm(struct s_smc *smc, const int np, int event); +void pcm_init(struct s_smc *smc); +void cfm(struct s_smc *smc, int event); +void cfm_init(struct s_smc *smc); +void smt_timer_start(struct s_smc *smc, struct smt_timer *timer, u_long time, + u_long token); +void smt_timer_stop(struct s_smc *smc, struct smt_timer *timer); +void pcm_status_state(struct s_smc *smc, int np, int *type, int *state, + int *remote, int *mac); +void plc_config_mux(struct s_smc *smc, int mux); +void sm_lem_evaluate(struct s_smc *smc); +void smt_clear_una_dna(struct s_smc *smc); +void mac_update_counter(struct s_smc *smc); +void sm_pm_ls_latch(struct s_smc *smc, int phy, int on_off); +void sm_ma_control(struct s_smc *smc, int mode); +void sm_mac_check_beacon_claim(struct s_smc *smc); +void config_mux(struct s_smc *smc, int mux); +void smt_agent_init(struct s_smc *smc); +void smt_timer_init(struct s_smc *smc); +void smt_received_pack(struct s_smc *smc, SMbuf *mb, int fs); +void smt_add_para(struct s_smc *smc, struct s_pcon *pcon, u_short para, + int index, int local); +void smt_swap_para(struct smt_header *sm, int len, int direction); +void ev_init(struct s_smc *smc); +void hwt_init(struct s_smc *smc); +u_long hwt_read(struct s_smc *smc); +void hwt_stop(struct s_smc *smc); +void hwt_start(struct s_smc *smc, u_long time); +void smt_send_mbuf(struct s_smc *smc, SMbuf *mb, int fc); +void smt_free_mbuf(struct s_smc *smc, SMbuf *mb); +void sm_pm_bypass_req(struct s_smc *smc, int mode); +void rmt_indication(struct s_smc *smc, int i); +void cfm_state_change(struct s_smc *smc, int c_state); + +#if defined(DEBUG) || !defined(NO_SMT_PANIC) +void smt_panic(struct s_smc *smc, char *text); #else #define smt_panic(smc,text) -#endif /* DEBUG */ -#endif /* NO_SMT_PANIC */ -void smt_stat_counter() ; -void smt_timer_poll() ; -u_long smt_get_time() ; -u_long smt_get_tid() ; -void smt_timer_done() ; -void smt_set_defaults() ; -void smt_fixup_mib() ; -void smt_reset_defaults() ; -void smt_agent_task() ; -void smt_please_reconnect() ; -int smt_check_para() ; -void driver_get_bia() ; -#ifdef SUPERNET_3 -void drv_reset_indication() ; +#endif /* DEBUG || !NO_SMT_PANIC */ + +void smt_stat_counter(struct s_smc *smc, int stat); +void smt_timer_poll(struct s_smc *smc); +u_long smt_get_time(void); +u_long smt_get_tid(struct s_smc *smc); +void smt_timer_done(struct s_smc *smc); +void smt_set_defaults(struct s_smc *smc); +void smt_fixup_mib(struct s_smc *smc); +void smt_reset_defaults(struct s_smc *smc, int level); +void smt_agent_task(struct s_smc *smc); +void smt_please_reconnect(struct s_smc *smc, int reconn_time); +int smt_check_para(struct s_smc *smc, struct smt_header *sm, + const u_short list[]); +void driver_get_bia(struct s_smc *smc, struct fddi_addr *bia_addr); + +#ifdef SUPERNET_3 +void drv_reset_indication(struct s_smc *smc); #endif /* SUPERNET_3 */ -void smt_start_watchdog() ; -void smt_event() ; -void pcm_event() ; -void rmt_event() ; -void cfm_event() ; -void timer_event() ; -void ev_dispatcher() ; - -void smt_get_state() ; -void ecm_get_state() ; -void pcm_get_state() ; -void rmt_get_state() ; - -void ecm_state_change() ; -int sm_pm_bypass_present() ; -void pcm_state_change() ; -void rmt_state_change() ; -int sm_pm_get_ls() ; -int pcm_get_s_port() ; -int pcm_rooted_station() ; -int cfm_get_mac_input() ; -int cfm_get_mac_output() ; -int port_to_mib() ; -int cem_build_path() ; -int sm_mac_get_tx_state() ; -int is_individual() ; -int is_my_addr() ; -int is_broadcast() ; -int is_equal() ; -char *get_pcmstate() ; - -int smt_action() ; -u_short smt_online() ; -void smt_force_irq() ; -void smt_pmf_received_pack() ; -void smt_send_frame() ; -void smt_set_timestamp() ; -void mac_set_rx_mode() ; -int mac_add_multicast() ; -int mac_set_func_addr() ; -void mac_del_multicast() ; -void mac_update_multicast() ; -void mac_clear_multicast() ; -void mac_rx_directed_beacon() ; -void set_formac_tsync() ; -void formac_reinit_tx() ; -void formac_tx_restart() ; -void process_receive() ; -void init_driver_fplus() ; - -void rtm_irq() ; -void rtm_set_timer() ; -void ring_status_indication() ; -void llc_recover_tx() ; -void llc_restart_tx() ; -void plc_clear_irq() ; -void plc_irq() ; -int smt_set_mac_opvalues() ; -#ifdef TAG_MODE -void mac_drv_pci_fix() ; -void mac_do_pci_fix() ; -void mac_drv_clear_tx_queue() ; -void mac_drv_repair_descr() ; -u_long hwt_quick_read() ; -void hwt_wait_time() ; +void smt_start_watchdog(struct s_smc *smc); +void smt_event(struct s_smc *smc, int event); +void timer_event(struct s_smc *smc, u_long token); +void ev_dispatcher(struct s_smc *smc); +void pcm_get_state(struct s_smc *smc, struct smt_state *state); +void ecm_state_change(struct s_smc *smc, int e_state); +int sm_pm_bypass_present(struct s_smc *smc); +void pcm_state_change(struct s_smc *smc, int plc, int p_state); +void rmt_state_change(struct s_smc *smc, int r_state); +int sm_pm_get_ls(struct s_smc *smc, int phy); +int pcm_get_s_port(struct s_smc *smc); +int pcm_rooted_station(struct s_smc *smc); +int cfm_get_mac_input(struct s_smc *smc); +int cfm_get_mac_output(struct s_smc *smc); +int port_to_mib(struct s_smc *smc, int p); +int cem_build_path(struct s_smc *smc, char *to, int path_index); +int sm_mac_get_tx_state(struct s_smc *smc); +int is_individual(struct fddi_addr *addr); +int is_my_addr(struct s_smc *smc, struct fddi_addr *addr); +int is_broadcast(struct fddi_addr *addr); +int is_equal(struct fddi_addr *addr1, struct fddi_addr *addr2); +char *get_pcmstate(struct s_smc *smc, int np); +int smt_action(struct s_smc *smc, int class, int code, int index); +u_short smt_online(struct s_smc *smc, int on); +void smt_force_irq(struct s_smc *smc); +void smt_pmf_received_pack(struct s_smc *smc, SMbuf *mb, int local); +void smt_send_frame(struct s_smc *smc, SMbuf *mb, int fc, int local); +void smt_set_timestamp(struct s_smc *smc, u_char *p); +void mac_set_rx_mode(struct s_smc *smc, int mode); +int mac_add_multicast(struct s_smc *smc, struct fddi_addr *addr, int can); +int mac_set_func_addr(struct s_smc *smc, u_long f_addr); +void mac_del_multicast(struct s_smc *smc, struct fddi_addr *addr, int can); +void mac_update_multicast(struct s_smc *smc); +void mac_clear_multicast(struct s_smc *smc); +void set_formac_tsync(struct s_smc *smc, long sync_bw); +void formac_reinit_tx(struct s_smc *smc); +void formac_tx_restart(struct s_smc *smc); +void process_receive(struct s_smc *smc); +void init_driver_fplus(struct s_smc *smc); +void rtm_irq(struct s_smc *smc); +void rtm_set_timer(struct s_smc *smc); +void ring_status_indication(struct s_smc *smc, u_long status); +void llc_recover_tx(struct s_smc *smc); +void llc_restart_tx(struct s_smc *smc); +void plc_clear_irq(struct s_smc *smc, int p); +void plc_irq(struct s_smc *smc, int np, unsigned int cmd); +int smt_set_mac_opvalues(struct s_smc *smc); + +#ifdef TAG_MODE +void mac_drv_pci_fix(struct s_smc *smc, u_long fix_value); +void mac_do_pci_fix(struct s_smc *smc); +void mac_drv_clear_tx_queue(struct s_smc *smc); +void mac_drv_repair_descr(struct s_smc *smc); +u_long hwt_quick_read(struct s_smc *smc); +void hwt_wait_time(struct s_smc *smc, u_long start, long duration); #endif #ifdef SMT_PNMI -#ifdef ANSIC -int pnmi_init (struct s_smc* smc); -int pnmi_process_ndis_id (struct s_smc* smc, u_long ndis_oid, void* buf, - int len, int* BytesAccessed, int* BytesNeeded, u_char action); -#else -int pnmi_init (); -int pnmi_process_ndis_id (); -#endif +int pnmi_init(struct s_smc* smc); +int pnmi_process_ndis_id(struct s_smc *smc, u_long ndis_oid, void *buf, int len, + int *BytesAccessed, int *BytesNeeded, u_char action); #endif #ifdef SBA #ifndef _H2INC -void sba() ; +void sba(); #endif -void sba_raf_received_pack() ; -void sba_timer_poll() ; -void smt_init_sba() ; +void sba_raf_received_pack(); +void sba_timer_poll(); +void smt_init_sba(); #endif + #ifdef ESS -int ess_raf_received_pack() ; -void ess_timer_poll() ; -void ess_para_change() ; +int ess_raf_received_pack(struct s_smc *smc, SMbuf *mb, struct smt_header *sm, + int fs); +void ess_timer_poll(struct s_smc *smc); +void ess_para_change(struct s_smc *smc); #endif -#ifdef BOOT -#define smt_srf_event(a,b,c,d) -#define smt_init_evc(a) +#ifndef BOOT +void smt_init_evc(struct s_smc *smc); +void smt_srf_event(struct s_smc *smc, int code, int index, int cond); #else -void smt_init_evc() ; -void smt_srf_event() ; +#define smt_init_evc(smc) +#define smt_srf_event(smc,code,index,cond) #endif #ifndef SMT_REAL_TOKEN_CT -void smt_emulate_token_ct(); +void smt_emulate_token_ct(struct s_smc *smc, int mac_index); #endif #if defined(DEBUG) && !defined(BOOT) -void dump_smt() ; +void dump_smt(struct s_smc *smc, struct smt_header *sm, char *text); #else #define dump_smt(smc,sm,text) #endif #ifdef DEBUG -char *addr_to_string() ; -void dump_hex() ; +char* addr_to_string(struct fddi_addr *addr); +void dump_hex(char *p, int len); #endif + #endif /* PROTOTYP_INC */ /* PNMI default defines */ diff -Nru a/drivers/net/skfp/h/smtstate.h b/drivers/net/skfp/h/smtstate.h --- a/drivers/net/skfp/h/smtstate.h 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/h/smtstate.h 2004-06-17 14:49:49 -07:00 @@ -12,6 +12,9 @@ * ******************************************************************************/ +#ifndef _SKFP_H_SMTSTATE_H_ +#define _SKFP_H_SMTSTATE_H_ + /* * SMT state definitions */ @@ -98,3 +101,6 @@ struct smt_state { struct pcm_state pcm_state[NUMPHYS] ; /* port A & port B */ } ; + +#endif + diff -Nru a/drivers/net/skfp/hwmtm.c b/drivers/net/skfp/hwmtm.c --- a/drivers/net/skfp/hwmtm.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/hwmtm.c 2004-06-17 14:49:49 -07:00 @@ -75,15 +75,17 @@ ------------------------------------------------------------- */ -static void queue_llc_rx(), smt_to_llc(), - init_txd_ring(), init_rxd_ring(), - queue_txd_mb() ; - -static u_long init_descr_ring(), repair_txd_ring(), - repair_rxd_ring() ; - -static SMbuf *get_llc_rx(), *get_txd_mb() ; - +static void queue_llc_rx(struct s_smc *smc, SMbuf *mb); +static void smt_to_llc(struct s_smc *smc, SMbuf *mb); +static void init_txd_ring(struct s_smc *smc); +static void init_rxd_ring(struct s_smc *smc); +static void queue_txd_mb(struct s_smc *smc, SMbuf *mb); +static u_long init_descr_ring(struct s_smc *smc, union s_fp_descr volatile *start, + int count); +static u_long repair_txd_ring(struct s_smc *smc, struct s_smt_tx_queue *queue); +static u_long repair_rxd_ring(struct s_smc *smc, struct s_smt_rx_queue *queue); +static SMbuf* get_llc_rx(struct s_smc *smc); +static SMbuf* get_txd_mb(struct s_smc *smc); /* ------------------------------------------------------------- @@ -92,55 +94,81 @@ */ /* The external SMT functions are listed in cmtdef.h */ -extern void *mac_drv_get_space(), *mac_drv_get_desc_mem(), - init_board(), mac_drv_fill_rxd(), - plc1_irq(), mac_drv_tx_complete(), - plc2_irq(), mac1_irq(), - mac2_irq(), mac3_irq(), - timer_irq(), mac_drv_rx_complete(), - mac_drv_requeue_rxd(), init_plc(), - mac_drv_clear_rxd(), llc_restart_tx(), - ev_dispatcher(), smt_force_irq() ; +extern void* mac_drv_get_space(struct s_smc *smc, unsigned int size); +extern void* mac_drv_get_desc_mem(struct s_smc *smc, unsigned int size); +extern void init_board(struct s_smc *smc, u_char *mac_addr); +extern void mac_drv_fill_rxd(struct s_smc *smc); +extern void plc1_irq(struct s_smc *smc); +extern void mac_drv_tx_complete(struct s_smc *smc, + volatile struct s_smt_fp_txd *txd); +extern void plc2_irq(struct s_smc *smc); +extern void mac1_irq(struct s_smc *smc, u_short stu, u_short stl); +extern void mac2_irq(struct s_smc *smc, u_short code_s2u, u_short code_s2l); +extern void mac3_irq(struct s_smc *smc, u_short code_s3u, u_short code_s3l); +extern void timer_irq(struct s_smc *smc); +extern void mac_drv_rx_complete(struct s_smc *smc, + volatile struct s_smt_fp_rxd *rxd, + int frag_count, int len); +extern void mac_drv_requeue_rxd(struct s_smc *smc, + volatile struct s_smt_fp_rxd *rxd, + int frag_count); +extern void init_plc(struct s_smc *smc); +extern void mac_drv_clear_rxd(struct s_smc *smc, + volatile struct s_smt_fp_rxd *rxd, int frag_count); #ifdef USE_OS_CPY -extern void hwm_cpy_rxd2mb(), hwm_cpy_txd2mb() ; +extern void hwm_cpy_rxd2mb(void); +extern void hwm_cpy_txd2mb(void); #endif + #ifdef ALL_RX_COMPLETE -extern void mac_drv_all_receives_complete() ; +extern void mac_drv_all_receives_complete(void); #endif -extern u_long mac_drv_virt2phys(), dma_master() ; +extern u_long mac_drv_virt2phys(struct s_smc *smc, void *virt); +extern u_long dma_master(struct s_smc *smc, void *virt, int len, int flag); #ifdef NDIS_OS2 -extern void post_proc() ; +extern void post_proc(void); #else -extern void dma_complete() ; +extern void dma_complete(struct s_smc *smc, volatile union s_fp_descr *descr, + int flag); #endif -extern int init_fplus(), mac_drv_rx_init() ; +extern int init_fplus(struct s_smc *smc); +extern int mac_drv_rx_init(struct s_smc *smc, int len, int fc, char *look_ahead, + int la_len); /* ------------------------------------------------------------- PUBLIC FUNCTIONS: ------------------------------------------------------------- */ - void process_receive(), smt_send_mbuf(), - fddi_isr(), mac_drv_clear_txd(), - smt_free_mbuf(), init_driver_fplus(), - mac_drv_rx_mode(), init_fddi_driver(), - mac_drv_clear_tx_queue(), - mac_drv_clear_rx_queue(), - hwm_tx_frag(), hwm_rx_frag() ; - - int mac_drv_rx_frag(), mac_drv_init(), - hwm_tx_init() ; +void process_receive(struct s_smc *smc); +void fddi_isr(struct s_smc *smc); +void mac_drv_clear_txd(struct s_smc *smc); +void smt_free_mbuf(struct s_smc *smc, SMbuf *mb); +void init_driver_fplus(struct s_smc *smc); +void mac_drv_rx_mode(struct s_smc *smc, int mode); +void init_fddi_driver(struct s_smc *smc, u_char *mac_addr); +void mac_drv_clear_tx_queue(struct s_smc *smc); +void mac_drv_clear_rx_queue(struct s_smc *smc); +void hwm_tx_frag(struct s_smc *smc, char far *virt, u_long phys, int len, + int frame_status); +void hwm_rx_frag(struct s_smc *smc, char far *virt, u_long phys, int len, + int frame_status); + +int mac_drv_rx_frag(struct s_smc *smc, void far *virt, int len); +int mac_drv_init(struct s_smc *smc); +int hwm_tx_init(struct s_smc *smc, u_char fc, int frag_count, int frame_len, + int frame_status); - u_int mac_drv_check_space() ; +u_int mac_drv_check_space(void); - SMbuf *smt_get_mbuf() ; +SMbuf* smt_get_mbuf(struct s_smc *smc); #ifdef DEBUG - void mac_drv_debug_lev() ; + void mac_drv_debug_lev(void); #endif /* @@ -208,7 +236,7 @@ * * END_MANUAL_ENTRY */ -u_int mac_drv_check_space() +u_int mac_drv_check_space(void) { #ifdef MB_OUTSIDE_SMC #ifdef COMMON_MB_POOL @@ -238,8 +266,7 @@ * mac_drv_init once, after the adatper is detected. * END_MANUAL_ENTRY */ -int mac_drv_init(smc) -struct s_smc *smc ; +int mac_drv_init(struct s_smc *smc) { if (sizeof(struct s_smt_fp_rxd) % 16) { SMT_PANIC(smc,HWM_E0001,HWM_E0001_MSG) ; @@ -289,8 +316,7 @@ * least significant byte etc.) * END_MANUAL_ENTRY */ -void init_driver_fplus(smc) -struct s_smc *smc ; +void init_driver_fplus(struct s_smc *smc) { smc->hw.fp.mdr2init = FM_LSB | FM_BMMODE | FM_ENNPRQ | FM_ENHSRQ | 3 ; @@ -305,10 +331,9 @@ #endif } -static u_long init_descr_ring(smc,start,count) -struct s_smc *smc ; -union s_fp_descr volatile *start; -int count ; +static u_long init_descr_ring(struct s_smc *smc, + union s_fp_descr volatile *start, + int count) { int i ; union s_fp_descr volatile *d1 ; @@ -337,8 +362,7 @@ return(phys) ; } -static void init_txd_ring(smc) -struct s_smc *smc ; +static void init_txd_ring(struct s_smc *smc) { struct s_smt_fp_txd volatile *ds ; struct s_smt_tx_queue *queue ; @@ -375,8 +399,7 @@ outpd(ADDR(B5_XS_DA),phys) ; } -static void init_rxd_ring(smc) -struct s_smc *smc ; +static void init_rxd_ring(struct s_smc *smc) { struct s_smt_fp_rxd volatile *ds ; struct s_smt_rx_queue *queue ; @@ -406,9 +429,7 @@ * * END_MANUAL_ENTRY */ -void init_fddi_driver(smc,mac_addr) -struct s_smc *smc ; -u_char *mac_addr ; /* canonical address */ +void init_fddi_driver(struct s_smc *smc, u_char *mac_addr) { SMbuf *mb ; int i ; @@ -472,8 +493,7 @@ } -SMbuf *smt_get_mbuf(smc) -struct s_smc *smc ; +SMbuf *smt_get_mbuf(struct s_smc *smc) { register SMbuf *mb ; @@ -495,9 +515,7 @@ return (mb) ; /* May be NULL */ } -void smt_free_mbuf(smc, mb) -struct s_smc *smc ; -SMbuf *mb; +void smt_free_mbuf(struct s_smc *smc, SMbuf *mb) { if (mb) { @@ -543,8 +561,7 @@ * * END_MANUAL_ENTRY */ -void mac_drv_repair_descr(smc) -struct s_smc *smc ; +void mac_drv_repair_descr(struct s_smc *smc) { u_long phys ; @@ -576,9 +593,7 @@ outpd(ADDR(B0_R1_CSR),CSR_START) ; } -static u_long repair_txd_ring(smc,queue) -struct s_smc *smc ; -struct s_smt_tx_queue *queue ; +static u_long repair_txd_ring(struct s_smc *smc, struct s_smt_tx_queue *queue) { int i ; int tx_used ; @@ -630,9 +645,7 @@ * RxDs with an OWN bit set but with a reset STF bit should be * skipped and owned by the driver (OWN = 0). */ -static u_long repair_rxd_ring(smc,queue) -struct s_smc *smc ; -struct s_smt_rx_queue *queue ; +static u_long repair_rxd_ring(struct s_smc *smc, struct s_smt_rx_queue *queue) { int i ; int rx_used ; @@ -703,8 +716,7 @@ * * END_MANUAL_ENTRY */ -void fddi_isr(smc) -struct s_smc *smc ; +void fddi_isr(struct s_smc *smc) { u_long is ; /* ISR source */ u_short stu, stl ; @@ -987,9 +999,7 @@ * * END_MANUAL_ENTRY */ -void mac_drv_rx_mode(smc,mode) -struct s_smc *smc ; -int mode ; +void mac_drv_rx_mode(struct s_smc *smc, int mode) { switch(mode) { case RX_ENABLE_PASS_SMT: @@ -1038,8 +1048,7 @@ /* * process receive queue */ -void process_receive(smc) -struct s_smc *smc ; +void process_receive(struct s_smc *smc) { int i ; int n ; @@ -1379,9 +1388,7 @@ return ; /* lint bug: needs return detect end of function */ } -static void smt_to_llc(smc,mb) -struct s_smc *smc ; -SMbuf *mb ; +static void smt_to_llc(struct s_smc *smc, SMbuf *mb) { u_char fc ; @@ -1416,12 +1423,8 @@ * * END_MANUAL_ENTRY */ -void hwm_rx_frag(smc,virt,phys,len,frame_status) -struct s_smc *smc ; -char far *virt ; -u_long phys ; -int len ; -int frame_status ; +void hwm_rx_frag(struct s_smc *smc, char far *virt, u_long phys, int len, + int frame_status) { struct s_smt_fp_rxd volatile *r ; u_int rbctrl ; @@ -1460,10 +1463,7 @@ * * END_MANUAL_ENTRY */ -int mac_drv_rx_frag(smc,virt,len) -struct s_smc *smc ; -void far *virt ; -int len ; +int mac_drv_rx_frag(struct s_smc *smc, void far *virt, int len) { NDD_TRACE("RHSB",virt,len,smc->os.hwm.r.mb_pos) ; @@ -1500,8 +1500,7 @@ * * END_MANUAL_ENTRY */ -void mac_drv_clear_rx_queue(smc) -struct s_smc *smc ; +void mac_drv_clear_rx_queue(struct s_smc *smc) { struct s_smt_fp_rxd volatile *r ; struct s_smt_fp_rxd volatile *next_rxd ; @@ -1588,12 +1587,8 @@ * * END_MANUAL_ENTRY */ -int hwm_tx_init(smc,fc,frag_count,frame_len,frame_status) -struct s_smc *smc ; -u_char fc ; -int frag_count ; -int frame_len ; -int frame_status ; +int hwm_tx_init(struct s_smc *smc, u_char fc, int frag_count, int frame_len, + int frame_status) { NDD_TRACE("THiB",fc,frag_count,frame_len) ; smc->os.hwm.tx_p = smc->hw.fp.tx[frame_status & QUEUE_A0] ; @@ -1670,12 +1665,8 @@ * * END_MANUAL_ENTRY */ -void hwm_tx_frag(smc,virt,phys,len,frame_status) -struct s_smc *smc ; -char far *virt ; -u_long phys ; -int len ; -int frame_status ; +void hwm_tx_frag(struct s_smc *smc, char far *virt, u_long phys, int len, + int frame_status) { struct s_smt_fp_txd volatile *t ; struct s_smt_tx_queue *queue ; @@ -1780,9 +1771,7 @@ /* * queues a receive for later send */ -static void queue_llc_rx(smc,mb) -struct s_smc *smc ; -SMbuf *mb ; +static void queue_llc_rx(struct s_smc *smc, SMbuf *mb) { DB_GEN("queue_llc_rx: mb = %x",(void *)mb,0,4) ; smc->os.hwm.queued_rx_frames++ ; @@ -1806,8 +1795,7 @@ /* * get a SMbuf from the llc_rx_queue */ -static SMbuf *get_llc_rx(smc) -struct s_smc *smc ; +static SMbuf *get_llc_rx(struct s_smc *smc) { SMbuf *mb ; @@ -1823,9 +1811,7 @@ * queues a transmit SMT MBuf during the time were the MBuf is * queued the TxD ring */ -static void queue_txd_mb(smc,mb) -struct s_smc *smc ; -SMbuf *mb ; +static void queue_txd_mb(struct s_smc *smc, SMbuf *mb) { DB_GEN("_rx: queue_txd_mb = %x",(void *)mb,0,4) ; smc->os.hwm.queued_txd_mb++ ; @@ -1842,8 +1828,7 @@ /* * get a SMbuf from the txd_tx_queue */ -static SMbuf *get_txd_mb(smc) -struct s_smc *smc ; +static SMbuf *get_txd_mb(struct s_smc *smc) { SMbuf *mb ; @@ -1858,10 +1843,7 @@ /* * SMT Send function */ -void smt_send_mbuf(smc,mb,fc) -struct s_smc *smc; -SMbuf *mb; -int fc; +void smt_send_mbuf(struct s_smc *smc, SMbuf *mb, int fc) { char far *data ; int len ; @@ -1995,8 +1977,7 @@ * * END_MANUAL_ENTRY */ -void mac_drv_clear_txd(smc) -struct s_smc *smc ; +void mac_drv_clear_txd(struct s_smc *smc) { struct s_smt_tx_queue *queue ; struct s_smt_fp_txd volatile *t1 ; @@ -2087,8 +2068,7 @@ * * END_MANUAL_ENTRY */ -void mac_drv_clear_tx_queue(smc) -struct s_smc *smc ; +void mac_drv_clear_tx_queue(struct s_smc *smc) { struct s_smt_fp_txd volatile *t ; struct s_smt_tx_queue *queue ; @@ -2180,10 +2160,7 @@ * * END_MANUAL_ENTRY */ -void mac_drv_debug_lev(smc,flag,lev) -struct s_smc *smc ; -int flag ; -int lev ; +void mac_drv_debug_lev(struct s_smc *smc, int flag, int lev) { switch(flag) { case (int)NULL: diff -Nru a/drivers/net/skfp/hwt.c b/drivers/net/skfp/hwt.c --- a/drivers/net/skfp/hwt.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/hwt.c 2004-06-17 14:49:49 -07:00 @@ -39,7 +39,7 @@ * Prototypes of local functions. */ /* 28-Jun-1994 sw - Note: hwt_restart() is also used in module 'drvfbi.c'. */ -/*static*/ void hwt_restart() ; +/*static void hwt_restart() ; */ /************************ * @@ -60,9 +60,7 @@ ************************/ #define HWT_MAX (65000) -void hwt_start(smc, time) -struct s_smc *smc ; -u_long time ; +void hwt_start(struct s_smc *smc, u_long time) { u_short cnt ; @@ -115,8 +113,7 @@ * Nothing. * ************************/ -void hwt_stop(smc) -struct s_smc *smc ; +void hwt_stop(struct s_smc *smc) { #ifndef PCI /* stop counter 0 by switching to mode 0 */ @@ -145,8 +142,7 @@ * Nothing. * ************************/ -void hwt_init(smc) -struct s_smc *smc ; +void hwt_init(struct s_smc *smc) { smc->hw.t_start = 0 ; smc->hw.t_stop = 0 ; @@ -169,8 +165,7 @@ * Nothing. * ************************/ -void hwt_restart(smc) -struct s_smc *smc ; +void hwt_restart(struct s_smc *smc) { hwt_stop(smc) ; #ifndef PCI @@ -193,8 +188,7 @@ * The elapsed time since last start in units of 16us. * ************************/ -u_long hwt_read(smc) -struct s_smc *smc ; +u_long hwt_read(struct s_smc *smc) { u_short tr ; #ifndef PCI @@ -238,8 +232,7 @@ * current timer value in units of 80ns. * ************************/ -u_long hwt_quick_read(smc) -struct s_smc *smc ; +u_long hwt_quick_read(struct s_smc *smc) { u_long interval ; u_long time ; @@ -267,10 +260,7 @@ * NOTE: The fuction will return immediately, if the timer is not * started ************************/ -void hwt_wait_time(smc,start,duration) -struct s_smc *smc ; -u_long start ; -long duration ; +void hwt_wait_time(struct s_smc *smc, u_long start, long int duration) { long diff ; long interval ; @@ -312,3 +302,4 @@ } } #endif + diff -Nru a/drivers/net/skfp/lnkstat.c b/drivers/net/skfp/lnkstat.c --- a/drivers/net/skfp/lnkstat.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/lnkstat.c 2004-06-17 14:49:49 -07:00 @@ -52,8 +52,7 @@ END_MANUAL_ENTRY() */ -u_long smt_get_error_word(smc) -struct s_smc *smc ; +u_long smt_get_error_word(struct s_smc *smc) { u_long st; @@ -92,8 +91,7 @@ END_MANUAL_ENTRY() */ -u_long smt_get_event_word(smc) -struct s_smc *smc ; +u_long smt_get_event_word(struct s_smc *smc) { return (u_long) 0; } @@ -111,8 +109,7 @@ END_MANUAL_ENTRY() */ -u_long smt_get_port_event_word(smc) -struct s_smc *smc ; +u_long smt_get_port_event_word(struct s_smc *smc) { return (u_long) 0; } @@ -135,10 +132,7 @@ END_MANUAL_ENTRY() */ -int smt_read_errorlog(smc,p,len) -struct s_smc *smc ; -char _far *p ; -int len ; +int smt_read_errorlog(struct s_smc *smc, char _far *p, int len) { int i ; int st ; @@ -207,3 +201,4 @@ er->ucode_version_level = 0x0101 ; return(len) ; } + diff -Nru a/drivers/net/skfp/pcmplc.c b/drivers/net/skfp/pcmplc.c --- a/drivers/net/skfp/pcmplc.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/pcmplc.c 2004-06-17 14:49:49 -07:00 @@ -199,28 +199,25 @@ PL_PCM_ENABLED | PL_SELF_TEST | PL_EBUF_ERR; /* external functions */ -void all_selection_criteria (); +void all_selection_criteria(struct s_smc *smc); /* internal functions */ -static void pcm_fsm() ; -static void pc_rcode_actions() ; -static void pc_tcode_actions() ; -static void reset_lem_struct() ; -static void plc_init() ; -static void sm_ph_lem_start() ; -static void sm_ph_lem_stop() ; -static void sm_ph_linestate() ; -static void real_init_plc() ; +static void pcm_fsm(struct s_smc *smc, struct s_phy *phy, int cmd); +static void pc_rcode_actions(struct s_smc *smc, int bit, struct s_phy *phy); +static void pc_tcode_actions(struct s_smc *smc, const int bit, struct s_phy *phy); +static void reset_lem_struct(struct s_phy *phy); +static void plc_init(struct s_smc *smc, int p); +static void sm_ph_lem_start(struct s_smc *smc, int np, int threshold); +static void sm_ph_lem_stop(struct s_smc *smc, int np); +static void sm_ph_linestate(struct s_smc *smc, int phy, int ls); +static void real_init_plc(struct s_smc *smc); /* * SMT timer interface * start PCM timer 0 */ -static void start_pcm_timer0(smc,value,event,phy) -struct s_smc *smc ; -u_long value; -int event; -struct s_phy *phy; +static void start_pcm_timer0(struct s_smc *smc, u_long value, int event, + struct s_phy *phy) { phy->timer0_exp = FALSE ; /* clear timer event flag */ smt_timer_start(smc,&phy->pcm_timer0,value, @@ -230,9 +227,7 @@ * SMT timer interface * stop PCM timer 0 */ -static void stop_pcm_timer0(smc,phy) -struct s_smc *smc ; -struct s_phy *phy; +static void stop_pcm_timer0(struct s_smc *smc, struct s_phy *phy) { if (phy->pcm_timer0.tm_active) smt_timer_stop(smc,&phy->pcm_timer0) ; @@ -242,8 +237,7 @@ init PCM state machine (called by driver) clear all PCM vars and flags */ -void pcm_init(smc) -struct s_smc *smc ; +void pcm_init(struct s_smc *smc) { int i ; int np ; @@ -407,8 +401,7 @@ real_init_plc(smc) ; } -void init_plc(smc) -struct s_smc *smc ; +void init_plc(struct s_smc *smc) { SK_UNUSED(smc) ; @@ -421,8 +414,7 @@ */ } -static void real_init_plc(smc) -struct s_smc *smc ; +static void real_init_plc(struct s_smc *smc) { int p ; @@ -430,9 +422,7 @@ plc_init(smc,p) ; } -static void plc_init(smc,p) -struct s_smc *smc ; -int p; +static void plc_init(struct s_smc *smc, int p) { int i ; #ifndef MOT_ELM @@ -495,10 +485,7 @@ /* * control PCM state machine */ -static void plc_go_state(smc,p,state) -struct s_smc *smc ; -int p; -int state; +static void plc_go_state(struct s_smc *smc, int p, int state) { HW_PTR port ; int val ; @@ -514,9 +501,7 @@ /* * read current line state (called by ECM & PCM) */ -int sm_pm_get_ls(smc,phy) -struct s_smc *smc ; -int phy; +int sm_pm_get_ls(struct s_smc *smc, int phy) { int state ; @@ -549,10 +534,7 @@ return(state) ; } -static int plc_send_bits(smc,phy,len) -struct s_smc *smc ; -struct s_phy *phy; -int len; +static int plc_send_bits(struct s_smc *smc, struct s_phy *phy, int len) { int np = phy->np ; /* PHY index */ int n ; @@ -589,9 +571,7 @@ /* * config plc muxes */ -void plc_config_mux(smc,mux) -struct s_smc *smc ; -int mux ; +void plc_config_mux(struct s_smc *smc, int mux) { if (smc->s.sas != SMT_DAS) return ; @@ -615,10 +595,7 @@ process event until SM is stable */ -void pcm(smc,np,event) -struct s_smc *smc ; -const int np; -int event; +void pcm(struct s_smc *smc, const int np, int event) { int state ; int oldstate ; @@ -697,10 +674,7 @@ /* * PCM state machine */ -static void pcm_fsm(smc,phy,cmd) -struct s_smc *smc ; -struct s_phy *phy; -int cmd; +static void pcm_fsm(struct s_smc *smc, struct s_phy *phy, int cmd) { int i ; int np = phy->np ; /* PHY index */ @@ -1063,10 +1037,7 @@ /* * force line state on a PHY output (only in MAINT state) */ -static void sm_ph_linestate(smc,phy,ls) -struct s_smc *smc ; -int phy; -int ls; +static void sm_ph_linestate(struct s_smc *smc, int phy, int ls) { int cntrl ; @@ -1095,9 +1066,7 @@ outpw(PLC(phy,PL_CNTRL_B),cntrl) ; } - -static void reset_lem_struct(phy) -struct s_phy *phy; +static void reset_lem_struct(struct s_phy *phy) { struct lem_counter *lem = &phy->lem ; @@ -1108,9 +1077,7 @@ /* * link error monitor */ -static void lem_evaluate(smc,phy) -struct s_smc *smc ; -struct s_phy *phy; +static void lem_evaluate(struct s_smc *smc, struct s_phy *phy) { int ber ; u_long errors ; @@ -1210,8 +1177,7 @@ /* * called by SMT to calculate LEM bit error rate */ -void sm_lem_evaluate(smc) -struct s_smc *smc ; +void sm_lem_evaluate(struct s_smc *smc) { int np ; @@ -1219,9 +1185,7 @@ lem_evaluate(smc,&smc->y[np]) ; } -static void lem_check_lct(smc,phy) -struct s_smc *smc ; -struct s_phy *phy ; +static void lem_check_lct(struct s_smc *smc, struct s_phy *phy) { struct lem_counter *lem = &phy->lem ; struct fddi_mib_p *mib ; @@ -1265,10 +1229,7 @@ /* * LEM functions */ -static void sm_ph_lem_start(smc,np,threshold) -struct s_smc *smc ; -int np; -int threshold; +static void sm_ph_lem_start(struct s_smc *smc, int np, int threshold) { struct lem_counter *lem = &smc->y[np].lem ; @@ -1286,9 +1247,7 @@ SETMASK(PLC(np,PL_INTR_MASK),PL_LE_CTR,PL_LE_CTR) ; } -static void sm_ph_lem_stop(smc,np) -struct s_smc *smc ; -int np; +static void sm_ph_lem_stop(struct s_smc *smc, int np) { struct lem_counter *lem = &smc->y[np].lem ; @@ -1297,10 +1256,8 @@ } /* ARGSUSED */ -void sm_pm_ls_latch(smc,phy,on_off) -struct s_smc *smc ; -int phy; -int on_off; /* en- or disable ident. ls */ +void sm_pm_ls_latch(struct s_smc *smc, int phy, int on_off) +/* int on_off; en- or disable ident. ls */ { SK_UNUSED(smc) ; @@ -1317,10 +1274,7 @@ /* * PCM pseudo code 5.1 .. 6.1 */ -static void pc_rcode_actions(smc,bit,phy) -struct s_smc *smc ; -int bit; -struct s_phy *phy; +static void pc_rcode_actions(struct s_smc *smc, int bit, struct s_phy *phy) { struct fddi_mib_p *mib ; @@ -1456,10 +1410,7 @@ /* * PCM pseudo code 5.1 .. 6.1 */ -static void pc_tcode_actions(smc,bit,phy) -struct s_smc *smc ; -const int bit; -struct s_phy *phy; +static void pc_tcode_actions(struct s_smc *smc, const int bit, struct s_phy *phy) { int np = phy->np ; struct fddi_mib_p *mib ; @@ -1638,8 +1589,7 @@ /* * return status twisted (called by SMT) */ -int pcm_status_twisted(smc) -struct s_smc *smc ; +int pcm_status_twisted(struct s_smc *smc) { int twist = 0 ; if (smc->s.sas != SMT_DAS) @@ -1658,13 +1608,8 @@ * remote phy type * remote mac yes/no */ -void pcm_status_state(smc,np,type,state,remote,mac) -struct s_smc *smc ; -int np; -int *type; -int *state; -int *remote; -int *mac; +void pcm_status_state(struct s_smc *smc, int np, int *type, int *state, + int *remote, int *mac) { struct s_phy *phy = &smc->y[np] ; struct fddi_mib_p *mib ; @@ -1687,8 +1632,7 @@ /* * return rooted station status (called by SMT) */ -int pcm_rooted_station(smc) -struct s_smc *smc ; +int pcm_rooted_station(struct s_smc *smc) { int n ; @@ -1703,10 +1647,8 @@ /* * Interrupt actions for PLC & PCM events */ -void plc_irq(smc,np,cmd) -struct s_smc *smc ; -int np; /* PHY index */ -unsigned int cmd; +void plc_irq(struct s_smc *smc, int np, unsigned int cmd) +/* int np; PHY index */ { struct s_phy *phy = &smc->y[np] ; struct s_plc *plc = &phy->plc ; @@ -1919,9 +1861,7 @@ #endif } -void pcm_set_lct_short(smc,n) -struct s_smc *smc ; -int n ; +void pcm_set_lct_short(struct s_smc *smc, int n) { if (n <= 0 || n > 1000) return ; @@ -1932,9 +1872,7 @@ /* * fill state struct */ -void pcm_get_state(smc,state) -struct s_smc *smc ; -struct smt_state *state ; +void pcm_get_state(struct s_smc *smc, struct smt_state *state) { struct s_phy *phy ; struct pcm_state *pcs ; @@ -1968,9 +1906,7 @@ } } -int get_pcm_state(smc,np) -struct s_smc *smc ; -int np; +int get_pcm_state(struct s_smc *smc, int np) { int pcs ; @@ -1992,9 +1928,7 @@ return(pcs) ; } -char *get_linestate(smc,np) -struct s_smc *smc ; -int np; +char *get_linestate(struct s_smc *smc, int np) { char *ls = "" ; @@ -2016,9 +1950,7 @@ return(ls) ; } -char *get_pcmstate(smc,np) -struct s_smc *smc ; -int np; +char *get_pcmstate(struct s_smc *smc, int np) { char *pcs ; @@ -2040,8 +1972,7 @@ return(pcs) ; } -void list_phy(smc) -struct s_smc *smc ; +void list_phy(struct s_smc *smc) { struct s_plc *plc ; int np ; @@ -2069,8 +2000,7 @@ #ifdef CONCENTRATOR -void pcm_lem_dump(smc) -struct s_smc *smc ; +void pcm_lem_dump(struct s_smc *smc) { int i ; struct s_phy *phy ; diff -Nru a/drivers/net/skfp/pmf.c b/drivers/net/skfp/pmf.c --- a/drivers/net/skfp/pmf.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/pmf.c 2004-06-17 14:49:49 -07:00 @@ -32,12 +32,16 @@ static const char ID_sccs[] = "@(#)pmf.c 1.37 97/08/04 (C) SK " ; #endif -static int smt_authorize() ; -static int smt_check_set_count() ; -static const struct s_p_tab *smt_get_ptab() ; -static int smt_mib_phys() ; -int smt_set_para() ; -void smt_add_para() ; +static int smt_authorize(struct s_smc *smc, struct smt_header *sm); +static int smt_check_set_count(struct s_smc *smc, struct smt_header *sm); +static const struct s_p_tab* smt_get_ptab(u_short para); +static int smt_mib_phys(struct s_smc *smc); +int smt_set_para(struct s_smc *smc, struct smt_para *pa, int index, int local, + int set); +void smt_add_para(struct s_smc *smc, struct s_pcon *pcon, u_short para, + int index, int local); +static SMbuf *smt_build_pmf_response(struct s_smc *smc, struct smt_header *req, + int set, int local); #define MOFFSS(e) ((int)&(((struct fddi_mib *)0)->e)) #define MOFFSA(e) ((int) (((struct fddi_mib *)0)->e)) @@ -280,13 +284,7 @@ { 0 } } ; - -static SMbuf *smt_build_pmf_response() ; - -void smt_pmf_received_pack(smc,mb,local) -struct s_smc *smc ; -SMbuf *mb ; -int local ; +void smt_pmf_received_pack(struct s_smc *smc, SMbuf *mb, int local) { struct smt_header *sm ; SMbuf *reply ; @@ -316,13 +314,8 @@ } } -extern SMbuf *smt_get_mbuf() ; - -static SMbuf *smt_build_pmf_response(smc,req,set,local) -struct s_smc *smc ; -struct smt_header *req ; -int set ; -int local ; +static SMbuf *smt_build_pmf_response(struct s_smc *smc, struct smt_header *req, + int set, int local) { SMbuf *mb ; struct smt_header *smt ; @@ -509,11 +502,7 @@ return(mb) ; } -extern void *sm_to_para() ; - -static int smt_authorize(smc,sm) -struct s_smc *smc ; -struct smt_header *sm ; +static int smt_authorize(struct s_smc *smc, struct smt_header *sm) { struct smt_para *pa ; int i ; @@ -548,9 +537,7 @@ return(0) ; } -static int smt_check_set_count(smc,sm) -struct s_smc *smc ; -struct smt_header *sm ; +static int smt_check_set_count(struct s_smc *smc, struct smt_header *sm) { struct smt_para *pa ; struct smt_p_setcount *sc ; @@ -566,12 +553,8 @@ return(0) ; } -void smt_add_para(smc,pcon,para,index,local) -struct s_smc *smc ; -struct s_pcon *pcon ; -u_short para ; -int index ; -int local ; +void smt_add_para(struct s_smc *smc, struct s_pcon *pcon, u_short para, + int index, int local) { struct smt_para *pa ; const struct s_p_tab *pt ; @@ -1095,12 +1078,8 @@ /* * set parameter */ -int smt_set_para(smc,pa,index,local,set) -struct s_smc *smc ; -struct smt_para *pa ; -int index ; -int local ; -int set ; +int smt_set_para(struct s_smc *smc, struct smt_para *pa, int index, int local, + int set) { #define IFSET(x) if (set) (x) @@ -1549,8 +1528,7 @@ #endif } -static const struct s_p_tab *smt_get_ptab(para) -u_short para ; +static const struct s_p_tab *smt_get_ptab(u_short para) { const struct s_p_tab *pt ; for (pt = p_tab ; pt->p_num && pt->p_num != para ; pt++) @@ -1558,8 +1536,7 @@ return(pt->p_num ? pt : 0) ; } -static int smt_mib_phys(smc) -struct s_smc *smc ; +static int smt_mib_phys(struct s_smc *smc) { #ifdef CONCENTRATOR SK_UNUSED(smc) ; @@ -1572,9 +1549,7 @@ #endif } -int port_to_mib(smc,p) -struct s_smc *smc ; -int p ; +int port_to_mib(struct s_smc *smc, int p) { #ifdef CONCENTRATOR SK_UNUSED(smc) ; @@ -1590,10 +1565,7 @@ #ifdef DEBUG #ifndef BOOT -void dump_smt(smc,sm,text) -struct s_smc *smc ; -struct smt_header *sm ; -char *text ; +void dump_smt(struct s_smc *smc, struct smt_header *sm, char *text) { int len ; struct smt_para *pa ; @@ -1680,9 +1652,7 @@ printf("-------------------------------------------------\n\n") ; } -void dump_hex(p,len) -char *p ; -int len ; +void dump_hex(char *p, int len) { int n = 0 ; while (len--) { diff -Nru a/drivers/net/skfp/queue.c b/drivers/net/skfp/queue.c --- a/drivers/net/skfp/queue.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/queue.c 2004-06-17 14:49:49 -07:00 @@ -31,8 +31,7 @@ /* * init event queue management */ -void ev_init(smc) -struct s_smc *smc ; +void ev_init(struct s_smc *smc) { smc->q.ev_put = smc->q.ev_get = smc->q.ev_queue ; } @@ -40,10 +39,7 @@ /* * add event to queue */ -void queue_event(smc,class,event) -struct s_smc *smc ; -int class ; -int event ; +void queue_event(struct s_smc *smc, int class, int event) { PRINTF("queue class %d event %d\n",class,event) ; smc->q.ev_put->class = class ; @@ -59,9 +55,7 @@ /* * timer_event is called from HW timer package. */ -void timer_event(smc,token) -struct s_smc *smc ; -u_long token ; +void timer_event(struct s_smc *smc, u_long token) { PRINTF("timer event class %d token %d\n", EV_T_CLASS(token), @@ -76,8 +70,7 @@ * send command to state machine * end */ -void ev_dispatcher(smc) -struct s_smc *smc ; +void ev_dispatcher(struct s_smc *smc) { struct event_queue *ev ; /* pointer into queue */ int class ; @@ -131,9 +124,7 @@ * on 0 disconnect * on 1 connect */ -u_short smt_online(smc,on) -struct s_smc *smc ; -int on ; +u_short smt_online(struct s_smc *smc, int on) { queue_event(smc,EVENT_ECM,on ? EC_CONNECT : EC_DISCONNECT) ; ev_dispatcher(smc) ; @@ -147,10 +138,7 @@ * dump current flag setting */ #ifdef CONCENTRATOR -void do_smt_flag(smc,flag,value) -struct s_smc *smc ; -char *flag ; -int value ; +void do_smt_flag(struct s_smc *smc, char *flag, int value) { #ifdef DEBUG struct smt_debug *deb; diff -Nru a/drivers/net/skfp/rmt.c b/drivers/net/skfp/rmt.c --- a/drivers/net/skfp/rmt.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/rmt.c 2004-06-17 14:49:49 -07:00 @@ -102,17 +102,17 @@ /* * function declarations */ -static void rmt_fsm() ; -static void start_rmt_timer0() ; -static void start_rmt_timer1() ; -static void start_rmt_timer2() ; -static void stop_rmt_timer0() ; -static void stop_rmt_timer1() ; -static void stop_rmt_timer2() ; -static void rmt_dup_actions() ; -static void rmt_reinsert_actions() ; -static void rmt_leave_actions() ; -static void rmt_new_dup_actions() ; +static void rmt_fsm(struct s_smc *smc, int cmd); +static void start_rmt_timer0(struct s_smc *smc, u_long value, int event); +static void start_rmt_timer1(struct s_smc *smc, u_long value, int event); +static void start_rmt_timer2(struct s_smc *smc, u_long value, int event); +static void stop_rmt_timer0(struct s_smc *smc); +static void stop_rmt_timer1(struct s_smc *smc); +static void stop_rmt_timer2(struct s_smc *smc); +static void rmt_dup_actions(struct s_smc *smc); +static void rmt_reinsert_actions(struct s_smc *smc); +static void rmt_leave_actions(struct s_smc *smc); +static void rmt_new_dup_actions(struct s_smc *smc); #ifndef SUPERNET_3 extern void restart_trt_for_dbcn() ; @@ -122,8 +122,7 @@ init RMT state machine clear all RMT vars and flags */ -void rmt_init(smc) -struct s_smc *smc ; +void rmt_init(struct s_smc *smc) { smc->mib.m[MAC0].fddiMACRMTState = ACTIONS(RM0_ISOLATED) ; smc->r.dup_addr_test = DA_NONE ; @@ -145,9 +144,7 @@ process event until SM is stable */ -void rmt(smc,event) -struct s_smc *smc ; -int event ; +void rmt(struct s_smc *smc, int event) { int state ; @@ -166,9 +163,7 @@ /* process RMT event */ -static void rmt_fsm(smc,cmd) -struct s_smc *smc ; -int cmd ; +static void rmt_fsm(struct s_smc *smc, int cmd) { /* * RM00-RM70 : from all states @@ -535,8 +530,7 @@ * (jd) RMT duplicate address actions * leave the ring or reinsert just as configured */ -static void rmt_dup_actions(smc) -struct s_smc *smc ; +static void rmt_dup_actions(struct s_smc *smc) { if (smc->r.jm_flag) { } @@ -555,8 +549,7 @@ /* * Reconnect to the Ring */ -static void rmt_reinsert_actions(smc) -struct s_smc *smc ; +static void rmt_reinsert_actions(struct s_smc *smc) { queue_event(smc,EVENT_ECM,EC_DISCONNECT) ; queue_event(smc,EVENT_ECM,EC_CONNECT) ; @@ -565,8 +558,7 @@ /* * duplicate address detected */ -static void rmt_new_dup_actions(smc) -struct s_smc *smc ; +static void rmt_new_dup_actions(struct s_smc *smc) { smc->r.da_flag = TRUE ; smc->r.bn_flag = FALSE ; @@ -591,8 +583,7 @@ /* * leave the ring */ -static void rmt_leave_actions(smc) -struct s_smc *smc ; +static void rmt_leave_actions(struct s_smc *smc) { queue_event(smc,EVENT_ECM,EC_DISCONNECT) ; /* @@ -605,10 +596,7 @@ * SMT timer interface * start RMT timer 0 */ -static void start_rmt_timer0(smc,value,event) -struct s_smc *smc ; -u_long value ; -int event ; +static void start_rmt_timer0(struct s_smc *smc, u_long value, int event) { smc->r.timer0_exp = FALSE ; /* clear timer event flag */ smt_timer_start(smc,&smc->r.rmt_timer0,value,EV_TOKEN(EVENT_RMT,event)); @@ -618,10 +606,7 @@ * SMT timer interface * start RMT timer 1 */ -static void start_rmt_timer1(smc,value,event) -struct s_smc *smc ; -u_long value ; -int event ; +static void start_rmt_timer1(struct s_smc *smc, u_long value, int event) { smc->r.timer1_exp = FALSE ; /* clear timer event flag */ smt_timer_start(smc,&smc->r.rmt_timer1,value,EV_TOKEN(EVENT_RMT,event)); @@ -631,10 +616,7 @@ * SMT timer interface * start RMT timer 2 */ -static void start_rmt_timer2(smc,value,event) -struct s_smc *smc ; -u_long value ; -int event ; +static void start_rmt_timer2(struct s_smc *smc, u_long value, int event) { smc->r.timer2_exp = FALSE ; /* clear timer event flag */ smt_timer_start(smc,&smc->r.rmt_timer2,value,EV_TOKEN(EVENT_RMT,event)); @@ -644,8 +626,7 @@ * SMT timer interface * stop RMT timer 0 */ -static void stop_rmt_timer0(smc) -struct s_smc *smc ; +static void stop_rmt_timer0(struct s_smc *smc) { if (smc->r.rmt_timer0.tm_active) smt_timer_stop(smc,&smc->r.rmt_timer0) ; @@ -655,8 +636,7 @@ * SMT timer interface * stop RMT timer 1 */ -static void stop_rmt_timer1(smc) -struct s_smc *smc ; +static void stop_rmt_timer1(struct s_smc *smc) { if (smc->r.rmt_timer1.tm_active) smt_timer_stop(smc,&smc->r.rmt_timer1) ; @@ -666,9 +646,9 @@ * SMT timer interface * stop RMT timer 2 */ -static void stop_rmt_timer2(smc) -struct s_smc *smc ; +static void stop_rmt_timer2(struct s_smc *smc) { if (smc->r.rmt_timer2.tm_active) smt_timer_stop(smc,&smc->r.rmt_timer2) ; } + diff -Nru a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c --- a/drivers/net/skfp/skfddi.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/skfddi.c 2004-06-17 14:49:49 -07:00 @@ -131,20 +131,10 @@ int frag_count); int mac_drv_rx_init(struct s_smc *smc, int len, int fc, char *look_ahead, int la_len); -void smt_timer_poll(struct s_smc *smc); -void ring_status_indication(struct s_smc *smc, u_long status); -unsigned long smt_get_time(void); -void smt_stat_counter(struct s_smc *smc, int stat); -void cfm_state_change(struct s_smc *smc, int c_state); -void ecm_state_change(struct s_smc *smc, int e_state); -void pcm_state_change(struct s_smc *smc, int plc, int p_state); -void rmt_state_change(struct s_smc *smc, int r_state); -void drv_reset_indication(struct s_smc *smc); void dump_data(unsigned char *Data, int length); - // External functions from the hardware module -extern u_int mac_drv_check_space(); +extern u_int mac_drv_check_space(void); extern void read_address(struct s_smc *smc, u_char * mac_addr); extern void card_stop(struct s_smc *smc); extern int mac_drv_init(struct s_smc *smc); @@ -157,9 +147,7 @@ extern void hwm_rx_frag(struct s_smc *smc, char far * virt, u_long phys, int len, int frame_status); extern void mac_drv_rx_mode(struct s_smc *smc, int mode); -extern void mac_drv_clear_tx_queue(struct s_smc *smc); extern void mac_drv_clear_rx_queue(struct s_smc *smc); -extern void mac_clear_multicast(struct s_smc *smc); extern void enable_tx_irq(struct s_smc *smc, u_short queue); extern void mac_drv_clear_txd(struct s_smc *smc); @@ -921,8 +909,7 @@ dmi = dev->mc_list; for (i = 0; i < dev->mc_count; i++) { - mac_add_multicast(smc, - dmi->dmi_addr, 1); + mac_add_multicast(smc, dmi->dmi_addr, 1); PRINTK(KERN_INFO "ENABLE MC ADDRESS:"); PRINTK(" %02x %02x %02x ", dmi->dmi_addr[0], diff -Nru a/drivers/net/skfp/smt.c b/drivers/net/skfp/smt.c --- a/drivers/net/skfp/smt.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/smt.c 2004-06-17 14:49:49 -07:00 @@ -62,68 +62,63 @@ /* * external functions */ -int pcm_status_twisted() ; -void pcm_status_state() ; -int pcm_status_type() ; +int pcm_status_twisted(struct s_smc *smc); -extern SMbuf *smt_get_mbuf() ; - -#define EXPORT_PMF /* * function prototypes */ -u_long smt_get_tid() ; -EXPORT_PMF SMbuf *smt_build_frame() ; -EXPORT_PMF void *sm_to_para() ; #ifdef LITTLE_ENDIAN -static int smt_swap_short() ; +static int smt_swap_short(u_short s); #endif -static int mac_index() ; -static int phy_index() ; -static int mac_con_resource_index() ; -static int phy_con_resource_index() ; -EXPORT_PMF void smt_send_frame() ; -EXPORT_PMF void smt_set_timestamp() ; -static void smt_send_rdf() ; -static void smt_send_nif() ; -static void smt_send_ecf() ; -static void smt_echo_test() ; -static void smt_send_sif_config() ; -static void smt_send_sif_operation() ; -EXPORT_PMF void smt_swap_para() ; +static int mac_index(struct s_smc *smc, int mac); +static int phy_index(struct s_smc *smc, int phy); +static int mac_con_resource_index(struct s_smc *smc, int mac); +static int phy_con_resource_index(struct s_smc *smc, int phy); +static void smt_send_rdf(struct s_smc *smc, SMbuf *rej, int fc, int reason, + int local); +static void smt_send_nif(struct s_smc *smc, struct fddi_addr *dest, int fc, + u_long tid, int type, int local); +static void smt_send_ecf(struct s_smc *smc, struct fddi_addr *dest, int fc, + u_long tid, int type, int len); +static void smt_echo_test(struct s_smc *smc, int dna); +static void smt_send_sif_config(struct s_smc *smc, struct fddi_addr *dest, + u_long tid, int local); +static void smt_send_sif_operation(struct s_smc *smc, struct fddi_addr *dest, + u_long tid, int local); #ifdef LITTLE_ENDIAN -static void smt_string_swap() ; +static void smt_string_swap(void); #endif -static void smt_add_frame_len() ; -static void smt_fill_una() ; -static void smt_fill_sde() ; -static void smt_fill_state() ; -static void smt_fill_timestamp() ; -static void smt_fill_policy() ; -static void smt_fill_latency() ; -static void smt_fill_neighbor() ; -static int smt_fill_path() ; -static void smt_fill_mac_status() ; -static void smt_fill_lem() ; -static void smt_fill_version() ; -static void smt_fill_fsc() ; -static void smt_fill_mac_counter() ; -static void smt_fill_mac_fnc() ; -static void smt_fill_manufacturer() ; -static void smt_fill_user() ; -static void smt_fill_setcount() ; -static void smt_fill_echo() ; -int smt_check_para() ; +static void smt_add_frame_len(SMbuf *mb, int len); +static void smt_fill_una(struct s_smc *smc, struct smt_p_una *una); +static void smt_fill_sde(struct s_smc *smc, struct smt_p_sde *sde); +static void smt_fill_state(struct s_smc *smc, struct smt_p_state *state); +static void smt_fill_timestamp(struct s_smc *smc, struct smt_p_timestamp *ts); +static void smt_fill_policy(struct s_smc *smc, struct smt_p_policy *policy); +static void smt_fill_latency(struct s_smc *smc, struct smt_p_latency *latency); +static void smt_fill_neighbor(struct s_smc *smc, struct smt_p_neighbor *neighbor); +static int smt_fill_path(struct s_smc *smc, struct smt_p_path *path); +static void smt_fill_mac_status(struct s_smc *smc, struct smt_p_mac_status *st); +static void smt_fill_lem(struct s_smc *smc, struct smt_p_lem *lem, int phy); +static void smt_fill_version(struct s_smc *smc, struct smt_p_version *vers); +static void smt_fill_fsc(struct s_smc *smc, struct smt_p_fsc *fsc); +static void smt_fill_mac_counter(struct s_smc *smc, struct smt_p_mac_counter *mc); +static void smt_fill_mac_fnc(struct s_smc *smc, struct smt_p_mac_fnc *fnc); +static void smt_fill_manufacturer(struct s_smc *smc, + struct smp_p_manufacturer *man); +static void smt_fill_user(struct s_smc *smc, struct smp_p_user *user); +static void smt_fill_setcount(struct s_smc *smc, struct smt_p_setcount *setcount); +static void smt_fill_echo(struct s_smc *smc, struct smt_p_echo *echo, u_long seed, + int len); -void smt_clear_una_dna() ; -static void smt_clear_old_una_dna() ; +void smt_clear_una_dna(struct s_smc *smc); +static void smt_clear_old_una_dna(struct s_smc *smc); #ifdef CONCENTRATOR -static int entity_to_index() ; +static int entity_to_index(void); #endif -static void update_dac() ; -static int div_ratio() ; +static void update_dac(struct s_smc *smc, int report); +static int div_ratio(u_long upper, u_long lower); #ifdef USE_CAN_ADDR -void hwm_conv_can() ; +void hwm_conv_can(struct s_smc *smc, char *data, int len); #else #define hwm_conv_can(smc,data,len) #endif @@ -136,8 +131,7 @@ /* * init SMT agent */ -void smt_agent_init(smc) -struct s_smc *smc ; +void smt_agent_init(struct s_smc *smc) { int i ; @@ -183,17 +177,16 @@ * check tvu & tvd * end */ -void smt_agent_task(smc) -struct s_smc *smc ; +void smt_agent_task(struct s_smc *smc) { smt_timer_start(smc,&smc->sm.smt_timer, (u_long)1000000L, EV_TOKEN(EVENT_SMT,SM_TIMER)) ; DB_SMT("SMT agent task\n",0,0) ; } -void smt_please_reconnect(smc,reconn_time) -struct s_smc *smc ; /* Pointer to SMT context */ -int reconn_time ; /* Wait for reconnect time in seconds */ +void smt_please_reconnect(struct s_smc *smc, int reconn_time) +/* struct s_smc *smc; Pointer to SMT context */ +/* int reconn_time; Wait for reconnect time in seconds */ { /* * The please reconnect variable is used as a timer. @@ -210,9 +203,7 @@ } #ifndef SMT_REAL_TOKEN_CT -void smt_emulate_token_ct(smc, mac_index) -struct s_smc *smc; -int mac_index; +void smt_emulate_token_ct(struct s_smc *smc, int mac_index) { u_long count; u_long time; @@ -239,9 +230,7 @@ #endif /*ARGSUSED1*/ -void smt_event(smc,event) -struct s_smc *smc ; -int event ; +void smt_event(struct s_smc *smc, int event) { u_long time ; #ifndef SMT_REAL_TOKEN_CT @@ -457,9 +446,7 @@ EV_TOKEN(EVENT_SMT,SM_TIMER)) ; } -static int div_ratio(upper,lower) -u_long upper ; -u_long lower ; +static int div_ratio(u_long upper, u_long lower) { if ((upper<<16L) < upper) upper = 0xffff0000L ; @@ -475,10 +462,8 @@ /* * receive packet handler */ -void smt_received_pack(smc,mb,fs) -struct s_smc *smc ; -SMbuf *mb ; -int fs ; /* frame status */ +void smt_received_pack(struct s_smc *smc, SMbuf *mb, int fs) +/* int fs; frame status */ { struct smt_header *sm ; int local ; @@ -823,9 +808,7 @@ smt_free_mbuf(smc,mb) ; } -static void update_dac(smc,report) -struct s_smc *smc ; -int report ; +static void update_dac(struct s_smc *smc, int report) { int cond ; @@ -843,11 +826,9 @@ * set station ID * send frame */ -EXPORT_PMF void smt_send_frame(smc,mb,fc,local) -struct s_smc *smc ; -SMbuf *mb ; /* buffer to send */ -int fc ; /* FC value */ -int local ; +void smt_send_frame(struct s_smc *smc, SMbuf *mb, int fc, int local) +/* SMbuf *mb; buffer to send */ +/* int fc; FC value */ { struct smt_header *sm ; @@ -868,12 +849,11 @@ /* * generate and send RDF */ -static void smt_send_rdf(smc,rej,fc,reason,local) -struct s_smc *smc ; -SMbuf *rej ; /* mbuf of offending frame */ -int fc ; /* FC of denied frame */ -int reason ; /* reason code */ -int local ; +static void smt_send_rdf(struct s_smc *smc, SMbuf *rej, int fc, int reason, + int local) +/* SMbuf *rej; mbuf of offending frame */ +/* int fc; FC of denied frame */ +/* int reason; reason code */ { SMbuf *mb ; struct smt_header *sm ; /* header of offending frame */ @@ -946,13 +926,12 @@ /* * generate and send NIF */ -static void smt_send_nif(smc,dest,fc,tid,type,local) -struct s_smc *smc ; -struct fddi_addr *dest ; /* dest address */ -int fc ; /* frame control */ -u_long tid ; /* transaction id */ -int type ; /* frame type */ -int local ; +static void smt_send_nif(struct s_smc *smc, struct fddi_addr *dest, int fc, + u_long tid, int type, int local) +/* struct fddi_addr *dest; dest address */ +/* int fc; frame control */ +/* u_long tid; transaction id */ +/* int type; frame type */ { struct smt_nif *nif ; SMbuf *mb ; @@ -976,9 +955,7 @@ /* * send NIF request (test purpose) */ -static void smt_send_nif_request(smc,dest) -struct s_smc *smc ; -struct fddi_addr *dest ; +static void smt_send_nif_request(struct s_smc *smc, struct fddi_addr *dest) { smc->sm.pend[SMT_TID_NIF_TEST] = smt_get_tid(smc) ; smt_send_nif(smc,dest, FC_SMT_INFO, smc->sm.pend[SMT_TID_NIF_TEST], @@ -988,10 +965,8 @@ /* * send ECF request (test purpose) */ -static void smt_send_ecf_request(smc,dest,len) -struct s_smc *smc ; -struct fddi_addr *dest ; -int len ; +static void smt_send_ecf_request(struct s_smc *smc, struct fddi_addr *dest, + int len) { smc->sm.pend[SMT_TID_ECF] = smt_get_tid(smc) ; smt_send_ecf(smc,dest, FC_SMT_INFO, smc->sm.pend[SMT_TID_ECF], @@ -1002,9 +977,7 @@ /* * echo test */ -static void smt_echo_test(smc,dna) -struct s_smc *smc ; -int dna ; +static void smt_echo_test(struct s_smc *smc, int dna) { u_long tid ; @@ -1019,13 +992,13 @@ /* * generate and send ECF */ -static void smt_send_ecf(smc,dest,fc,tid,type,len) -struct s_smc *smc ; -struct fddi_addr *dest ; /* dest address */ -int fc ; /* frame control */ -u_long tid ; /* transaction id */ -int type ; /* frame type */ -int len ; /* frame length */ +static void smt_send_ecf(struct s_smc *smc, struct fddi_addr *dest, int fc, + u_long tid, int type, int len) +/* struct fddi_addr *dest; dest address */ +/* int fc; frame control */ +/* u_long tid; transaction id */ +/* int type; frame type */ +/* int len; frame length */ { struct smt_ecf *ecf ; SMbuf *mb ; @@ -1045,11 +1018,10 @@ * generate and send SIF config response */ -static void smt_send_sif_config(smc,dest,tid,local) -struct s_smc *smc ; -struct fddi_addr *dest ; /* dest address */ -u_long tid ; /* transaction id */ -int local ; +static void smt_send_sif_config(struct s_smc *smc, struct fddi_addr *dest, + u_long tid, int local) +/* struct fddi_addr *dest; dest address */ +/* u_long tid; transaction id */ { struct smt_sif_config *sif ; SMbuf *mb ; @@ -1079,11 +1051,10 @@ * generate and send SIF operation response */ -static void smt_send_sif_operation(smc,dest,tid,local) -struct s_smc *smc ; -struct fddi_addr *dest ; /* dest address */ -u_long tid ; /* transaction id */ -int local ; +static void smt_send_sif_operation(struct s_smc *smc, struct fddi_addr *dest, + u_long tid, int local) +/* struct fddi_addr *dest; dest address */ +/* u_long tid; transaction id */ { struct smt_sif_operation *sif ; SMbuf *mb ; @@ -1128,11 +1099,8 @@ /* * get and initialize SMT frame */ -EXPORT_PMF SMbuf *smt_build_frame(smc,class,type,length) -struct s_smc *smc ; -int class ; -int type ; -int length ; +SMbuf *smt_build_frame(struct s_smc *smc, int class, int type, + int length) { SMbuf *mb ; struct smt_header *smt ; @@ -1167,9 +1135,7 @@ return(mb) ; } -static void smt_add_frame_len(mb,len) -SMbuf *mb ; -int len ; +static void smt_add_frame_len(SMbuf *mb, int len) { struct smt_header *smt ; @@ -1183,9 +1149,7 @@ /* * fill values in UNA parameter */ -static void smt_fill_una(smc,una) -struct s_smc *smc ; -struct smt_p_una *una ; +static void smt_fill_una(struct s_smc *smc, struct smt_p_una *una) { SMTSETPARA(una,SMT_P_UNA) ; una->una_pad = 0 ; @@ -1195,9 +1159,7 @@ /* * fill values in SDE parameter */ -static void smt_fill_sde(smc,sde) -struct s_smc *smc ; -struct smt_p_sde *sde ; +static void smt_fill_sde(struct s_smc *smc, struct smt_p_sde *sde) { SMTSETPARA(sde,SMT_P_SDE) ; sde->sde_non_master = smc->mib.fddiSMTNonMaster_Ct ; @@ -1213,9 +1175,7 @@ /* * fill in values in station state parameter */ -static void smt_fill_state(smc,state) -struct s_smc *smc ; -struct smt_p_state *state ; +static void smt_fill_state(struct s_smc *smc, struct smt_p_state *state) { int top ; int twist ; @@ -1255,18 +1215,14 @@ /* * fill values in timestamp parameter */ -static void smt_fill_timestamp(smc,ts) -struct s_smc *smc ; -struct smt_p_timestamp *ts ; +static void smt_fill_timestamp(struct s_smc *smc, struct smt_p_timestamp *ts) { SMTSETPARA(ts,SMT_P_TIMESTAMP) ; smt_set_timestamp(smc,ts->ts_time) ; } -EXPORT_PMF void smt_set_timestamp(smc,p) -struct s_smc *smc ; -u_char *p ; +void smt_set_timestamp(struct s_smc *smc, u_char *p) { u_long time ; u_long utime ; @@ -1300,9 +1256,7 @@ /* * fill values in station policy parameter */ -static void smt_fill_policy(smc,policy) -struct s_smc *smc ; -struct smt_p_policy *policy ; +static void smt_fill_policy(struct s_smc *smc, struct smt_p_policy *policy) { int i ; u_char *map ; @@ -1333,9 +1287,7 @@ /* * fill values in latency equivalent parameter */ -static void smt_fill_latency(smc,latency) -struct s_smc *smc ; -struct smt_p_latency *latency ; +static void smt_fill_latency(struct s_smc *smc, struct smt_p_latency *latency) { SMTSETPARA(latency,SMT_P_LATENCY) ; @@ -1358,9 +1310,7 @@ /* * fill values in MAC neighbors parameter */ -static void smt_fill_neighbor(smc,neighbor) -struct s_smc *smc ; -struct smt_p_neighbor *neighbor ; +static void smt_fill_neighbor(struct s_smc *smc, struct smt_p_neighbor *neighbor) { SMTSETPARA(neighbor,SMT_P_NEIGHBORS) ; @@ -1379,9 +1329,7 @@ #define ALLPHYS ((smc->s.sas == SMT_SAS) ? 1 : 2) #endif -static int smt_fill_path(smc,path) -struct s_smc *smc ; -struct smt_p_path *path ; +static int smt_fill_path(struct s_smc *smc, struct smt_p_path *path) { SK_LOC_DECL(int,type) ; SK_LOC_DECL(int,state) ; @@ -1429,9 +1377,7 @@ /* * fill values in mac status */ -static void smt_fill_mac_status(smc,st) -struct s_smc *smc ; -struct smt_p_mac_status *st ; +static void smt_fill_mac_status(struct s_smc *smc, struct smt_p_mac_status *st) { SMTSETPARA(st,SMT_P_MAC_STATUS) ; @@ -1458,11 +1404,7 @@ /* * fill values in LEM status */ - -static void smt_fill_lem(smc,lem,phy) -struct s_smc *smc ; -struct smt_p_lem *lem ; -int phy ; +static void smt_fill_lem(struct s_smc *smc, struct smt_p_lem *lem, int phy) { struct fddi_mib_p *mib ; @@ -1484,9 +1426,7 @@ /* * fill version parameter */ -static void smt_fill_version(smc,vers) -struct s_smc *smc ; -struct smt_p_version *vers ; +static void smt_fill_version(struct s_smc *smc, struct smt_p_version *vers) { SK_UNUSED(smc) ; SMTSETPARA(vers,SMT_P_VERSION) ; @@ -1505,9 +1445,7 @@ * note: this para 200B is NOT in swap table, because it's also set in * PMF add_para */ -static void smt_fill_fsc(smc,fsc) -struct s_smc *smc ; -struct smt_p_fsc *fsc ; +static void smt_fill_fsc(struct s_smc *smc, struct smt_p_fsc *fsc) { SK_UNUSED(smc) ; SMTSETPARA(fsc,SMT_P_FSC) ; @@ -1527,9 +1465,7 @@ /* * fill mac counter field */ -static void smt_fill_mac_counter(smc,mc) -struct s_smc *smc ; -struct smt_p_mac_counter *mc ; +static void smt_fill_mac_counter(struct s_smc *smc, struct smt_p_mac_counter *mc) { SMTSETPARA(mc,SMT_P_MAC_COUNTER) ; mc->mc_mib_index = INDEX_MAC ; @@ -1541,9 +1477,7 @@ /* * fill mac frame not copied counter */ -static void smt_fill_mac_fnc(smc,fnc) -struct s_smc *smc ; -struct smt_p_mac_fnc *fnc ; +static void smt_fill_mac_fnc(struct s_smc *smc, struct smt_p_mac_fnc *fnc) { SMTSETPARA(fnc,SMT_P_MAC_FNC) ; fnc->nc_mib_index = INDEX_MAC ; @@ -1555,9 +1489,8 @@ /* * fill manufacturer field */ -static void smt_fill_manufacturer(smc,man) -struct s_smc *smc ; -struct smp_p_manufacturer *man ; +static void smt_fill_manufacturer(struct s_smc *smc, + struct smp_p_manufacturer *man) { SMTSETPARA(man,SMT_P_MANUFACTURER) ; memcpy((char *) man->mf_data, @@ -1568,9 +1501,7 @@ /* * fill user field */ -static void smt_fill_user(smc,user) -struct s_smc *smc ; -struct smp_p_user *user ; +static void smt_fill_user(struct s_smc *smc, struct smp_p_user *user) { SMTSETPARA(user,SMT_P_USER) ; memcpy((char *) user->us_data, @@ -1578,14 +1509,10 @@ sizeof(user->us_data)) ; } - - /* * fill set count */ -static void smt_fill_setcount(smc,setcount) -struct s_smc *smc ; -struct smt_p_setcount *setcount ; +static void smt_fill_setcount(struct s_smc *smc, struct smt_p_setcount *setcount) { SK_UNUSED(smc) ; SMTSETPARA(setcount,SMT_P_SETCOUNT) ; @@ -1597,13 +1524,9 @@ /* * fill echo data */ -static void smt_fill_echo(smc,echo,seed,len) -struct s_smc *smc ; -struct smt_p_echo *echo ; -u_long seed ; -int len ; +static void smt_fill_echo(struct s_smc *smc, struct smt_p_echo *echo, u_long seed, + int len) { - u_char *p ; SK_UNUSED(smc) ; @@ -1619,22 +1542,19 @@ * clear DNA and UNA * called from CFM if configuration changes */ -void smt_clear_una_dna(smc) -struct s_smc *smc ; +void smt_clear_una_dna(struct s_smc *smc) { smc->mib.m[MAC0].fddiMACUpstreamNbr = SMT_Unknown ; smc->mib.m[MAC0].fddiMACDownstreamNbr = SMT_Unknown ; } -static void smt_clear_old_una_dna(smc) -struct s_smc *smc ; +static void smt_clear_old_una_dna(struct s_smc *smc) { smc->mib.m[MAC0].fddiMACOldUpstreamNbr = SMT_Unknown ; smc->mib.m[MAC0].fddiMACOldDownstreamNbr = SMT_Unknown ; } -u_long smt_get_tid(smc) -struct s_smc *smc ; +u_long smt_get_tid(struct s_smc *smc) { u_long tid ; while ((tid = ++(smc->sm.smt_tid) ^ SMT_TID_MAGIC) == 0) @@ -1723,10 +1643,8 @@ #define N_SMT_PLEN (sizeof(smt_pdef)/sizeof(smt_pdef[0])) -int smt_check_para(smc,sm,list) -struct s_smc *smc ; -struct smt_header *sm ; -const u_short list[] ; +int smt_check_para(struct s_smc *smc, struct smt_header *sm, + const u_short list[]) { const u_short *p = list ; while (*p) { @@ -1739,10 +1657,7 @@ return(0) ; } -EXPORT_PMF void *sm_to_para(smc,sm,para) -struct s_smc *smc ; -struct smt_header *sm ; -int para ; +void *sm_to_para(struct s_smc *smc, struct smt_header *sm, int para) { char *p ; int len ; @@ -1773,9 +1688,7 @@ return(0) ; } -int is_my_addr(smc,addr) -struct s_smc *smc ; -struct fddi_addr *addr ; +int is_my_addr(struct s_smc *smc, struct fddi_addr *addr) { return(*(short *)(&addr->a[0]) == *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[0]) @@ -1785,31 +1698,26 @@ *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[4])) ; } -int is_zero(addr) -struct fddi_addr *addr ; +int is_zero(struct fddi_addr *addr) { return(*(short *)(&addr->a[0]) == 0 && *(short *)(&addr->a[2]) == 0 && *(short *)(&addr->a[4]) == 0 ) ; } -int is_broadcast(addr) -struct fddi_addr *addr ; +int is_broadcast(struct fddi_addr *addr) { return(*(u_short *)(&addr->a[0]) == 0xffff && *(u_short *)(&addr->a[2]) == 0xffff && *(u_short *)(&addr->a[4]) == 0xffff ) ; } -int is_individual(addr) -struct fddi_addr *addr ; +int is_individual(struct fddi_addr *addr) { return(!(addr->a[0] & GROUP_ADDR)) ; } -int is_equal(addr1,addr2) -struct fddi_addr *addr1 ; -struct fddi_addr *addr2 ; +int is_equal(struct fddi_addr *addr1, struct fddi_addr *addr2) { return(*(u_short *)(&addr1->a[0]) == *(u_short *)(&addr2->a[0]) && *(u_short *)(&addr1->a[2]) == *(u_short *)(&addr2->a[2]) && @@ -1821,9 +1729,7 @@ /* * send ANTC data test frame */ -void fddi_send_antc(smc,dest) -struct s_smc *smc ; -struct fddi_addr *dest ; +void fddi_send_antc(struct s_smc *smc, struct fddi_addr *dest) { SK_UNUSED(smc) ; SK_UNUSED(dest) ; @@ -1850,8 +1756,7 @@ #ifdef DEBUG #define hextoasc(x) "0123456789abcdef"[x] -char *addr_to_string(addr) -struct fddi_addr *addr ; +char *addr_to_string(struct fddi_addr *addr) { int i ; static char string[6*3] = "****" ; @@ -1867,9 +1772,7 @@ #endif #ifdef AM29K -smt_ifconfig(argc,argv) -int argc ; -char *argv[] ; +smt_ifconfig(int argc, char *argv[]) { if (argc >= 2 && !strcmp(argv[0],"opt_bypass") && !strcmp(argv[1],"yes")) { @@ -1883,9 +1786,7 @@ /* * return static mac index */ -static int mac_index(smc,mac) -struct s_smc *smc ; -int mac ; +static int mac_index(struct s_smc *smc, int mac) { SK_UNUSED(mac) ; #ifdef CONCENTRATOR @@ -1899,9 +1800,7 @@ /* * return static phy index */ -static int phy_index(smc,phy) -struct s_smc *smc ; -int phy ; +static int phy_index(struct s_smc *smc, int phy) { SK_UNUSED(smc) ; return(phy+1); @@ -1910,9 +1809,7 @@ /* * return dynamic mac connection resource index */ -static int mac_con_resource_index(smc,mac) -struct s_smc *smc ; -int mac ; +static int mac_con_resource_index(struct s_smc *smc, int mac) { #ifdef CONCENTRATOR SK_UNUSED(smc) ; @@ -1936,9 +1833,7 @@ /* * return dynamic phy connection resource index */ -static int phy_con_resource_index(smc,phy) -struct s_smc *smc ; -int phy ; +static int phy_con_resource_index(struct s_smc *smc, int phy) { #ifdef CONCENTRATOR return(entity_to_index(smc,cem_get_downstream(smc,ENTITY_PHY(phy)))) ; @@ -1960,9 +1855,7 @@ } #ifdef CONCENTRATOR -static int entity_to_index(smc,e) -struct s_smc *smc ; -int e ; +static int entity_to_index(struct s_smc *smc, int e) { if (e == ENTITY_MAC) return(mac_index(smc,1)) ; @@ -1972,16 +1865,13 @@ #endif #ifdef LITTLE_ENDIAN -static int smt_swap_short(s) -u_short s ; +static int smt_swap_short(u_short s) { return(((s>>8)&0xff)|((s&0xff)<<8)) ; } -void smt_swap_para(sm,len,direction) -struct smt_header *sm ; -int len ; -int direction ; /* 0 encode 1 decode */ +void smt_swap_para(struct smt_header *sm, int len, int direction) +/* int direction; 0 encode 1 decode */ { struct smt_para *pa ; const struct smt_pdef *pd ; @@ -2027,10 +1917,7 @@ } } -static void smt_string_swap(data,format,len) -char *data ; -const char *format ; -int len ; +static void smt_string_swap(char *data, const char *format, int len) { const char *open_paren = 0 ; int x ; @@ -2081,10 +1968,8 @@ } } #else -void smt_swap_para(sm,len,direction) -struct smt_header *sm ; -int len ; -int direction ; /* 0 encode 1 decode */ +void smt_swap_para(struct smt_header *sm, int len, int direction) +/* int direction; 0 encode 1 decode */ { SK_UNUSED(sm) ; SK_UNUSED(len) ; @@ -2095,11 +1980,7 @@ /* * PMF actions */ -int smt_action(smc,class,code,index) -struct s_smc *smc ; -int class ; -int code ; -int index ; +int smt_action(struct s_smc *smc, int class, int code, int index) { int event ; int port ; @@ -2190,9 +2071,7 @@ * set reconnect * end */ -void smt_change_t_neg(smc,tneg) -struct s_smc *smc ; -u_long tneg ; +void smt_change_t_neg(struct s_smc *smc, u_long tneg) { smc->mib.a[PATH0].fddiPATHMaxT_Req = tneg ; @@ -2207,10 +2086,7 @@ * canonical conversion of bytes beginning form *data */ #ifdef USE_CAN_ADDR -void hwm_conv_can(smc,data,len) -struct s_smc *smc ; -char *data ; -int len ; +void hwm_conv_can(struct s_smc *smc, char *data, int len) { int i ; @@ -2223,3 +2099,4 @@ #endif #endif /* no SLIM_SMT */ + diff -Nru a/drivers/net/skfp/smtdef.c b/drivers/net/skfp/smtdef.c --- a/drivers/net/skfp/smtdef.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/smtdef.c 2004-06-17 14:49:49 -07:00 @@ -72,13 +72,11 @@ #define DEFAULT_LCT_EXTEND 50 /* Forward declarations */ -extern void smt_reset_defaults (); -static void smt_init_mib (); +void smt_reset_defaults(struct s_smc *smc, int level); +static void smt_init_mib(struct s_smc *smc, int level); +static int set_min_max(int maxflag, u_long mib, u_long limit, u_long *oper); -static int set_min_max() ; - -void smt_set_defaults(smc) -struct s_smc *smc ; +void smt_set_defaults(struct s_smc *smc) { smt_reset_defaults(smc,0) ; } @@ -86,9 +84,7 @@ #define MS2BCLK(x) ((x)*12500L) #define US2BCLK(x) ((x)*1250L) -void smt_reset_defaults(smc,level) -struct s_smc *smc ; -int level ; +void smt_reset_defaults(struct s_smc *smc, int level) { struct smt_config *smt ; int i ; @@ -170,9 +166,7 @@ /* 01234567890123456789012345678901 */ "xxxSK-NET FDDI SMT 7.3 - V2.8.8" ; -static void smt_init_mib(smc,level) -struct s_smc *smc ; -int level ; +static void smt_init_mib(struct s_smc *smc, int level) { struct fddi_mib *mib ; struct fddi_mib_p *pm ; @@ -292,8 +286,7 @@ (void) smt_set_mac_opvalues(smc) ; } -int smt_set_mac_opvalues(smc) -struct s_smc *smc ; +int smt_set_mac_opvalues(struct s_smc *smc) { int st ; int st2 ; @@ -318,8 +311,7 @@ return(st) ; } -void smt_fixup_mib(smc) -struct s_smc *smc ; +void smt_fixup_mib(struct s_smc *smc) { #ifdef CONCENTRATOR switch (smc->s.sas) { @@ -355,11 +347,7 @@ * use mib * NOTE : numbers are negative, negate comparison ! */ -static int set_min_max(maxflag,mib,limit,oper) -int maxflag ; -u_long mib ; -u_long limit ; -u_long *oper ; +static int set_min_max(int maxflag, u_long mib, u_long limit, u_long *oper) { u_long old ; old = *oper ; @@ -369,3 +357,4 @@ *oper = mib ; return(old != *oper) ; } + diff -Nru a/drivers/net/skfp/smtinit.c b/drivers/net/skfp/smtinit.c --- a/drivers/net/skfp/smtinit.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/smtinit.c 2004-06-17 14:49:49 -07:00 @@ -27,7 +27,7 @@ static const char ID_sccs[] = "@(#)smtinit.c 1.15 97/05/06 (C) SK " ; #endif -extern void init_fddi_driver() ; +void init_fddi_driver(struct s_smc *smc, u_char *mac_addr); /* define global debug variable */ #if defined(DEBUG) && !defined(DEBUG_BRD) @@ -48,8 +48,7 @@ * Can not be called in smt_reset_defaults, because it is not sure that * the OEM ID is already defined. */ -static void set_oem_spec_val(smc) -struct s_smc *smc ; +static void set_oem_spec_val(struct s_smc *smc) { struct fddi_mib *mib ; @@ -66,9 +65,8 @@ /* * Init SMT */ -int init_smt(smc,mac_addr) -struct s_smc *smc ; -u_char *mac_addr ; /* canonical address or NULL */ +int init_smt(struct s_smc *smc, u_char *mac_addr) +/* u_char *mac_addr; canonical address or NULL */ { int p ; @@ -124,3 +122,4 @@ return(0) ; } + diff -Nru a/drivers/net/skfp/smtparse.c b/drivers/net/skfp/smtparse.c --- a/drivers/net/skfp/smtparse.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/smtparse.c 2004-06-17 14:49:49 -07:00 @@ -82,8 +82,9 @@ /* * local function declarations */ -static u_long parse_num() ; -static int parse_word() ; +static u_long parse_num(int type, char _far *value, char *v, u_long mn, + u_long mx, int scale); +static int parse_word(char *buf, char _far *text); #ifdef SIM #define DB_MAIN(a,b,c) printf(a,b,c) @@ -117,11 +118,8 @@ * * END_MANUAL_ENTRY() */ -int smt_parse_arg(smc,keyword,type,value) -struct s_smc *smc ; -char _far *keyword ; -int type ; -char _far *value ; +int smt_parse_arg(struct s_smc *smc, char _far *keyword, int type, + char _far *value) { char keybuf[MAX_VAL+1]; char valbuf[MAX_VAL+1]; @@ -287,9 +285,7 @@ return(0) ; } -static int parse_word(buf,text) -char *buf ; -char _far *text ; +static int parse_word(char *buf, char _far *text) { char c ; char *p ; @@ -364,13 +360,8 @@ return(0) ; } -static u_long parse_num(type,value,v,mn,mx,scale) -int type ; -char _far *value ; -char *v ; -u_long mn ; -u_long mx ; -int scale ; +static u_long parse_num(int type, char _far *value, char *v, u_long mn, + u_long mx, int scale) { u_long x = 0 ; char c ; @@ -473,3 +464,4 @@ exit(0) ; } #endif + diff -Nru a/drivers/net/skfp/smttimer.c b/drivers/net/skfp/smttimer.c --- a/drivers/net/skfp/smttimer.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/smttimer.c 2004-06-17 14:49:49 -07:00 @@ -26,18 +26,9 @@ static const char ID_sccs[] = "@(#)smttimer.c 2.4 97/08/04 (C) SK " ; #endif -/* - * external function declarations - */ -extern u_long hwt_read() ; -extern void hwt_stop() ; -extern void hwt_start() ; +static void timer_done(struct s_smc *smc, int restart); -static void timer_done() ; - - -void smt_timer_init(smc) -struct s_smc *smc ; +void smt_timer_init(struct s_smc *smc) { smc->t.st_queue = 0 ; smc->t.st_fast.tm_active = FALSE ; @@ -45,9 +36,7 @@ hwt_init(smc) ; } -void smt_timer_stop(smc,timer) -struct s_smc *smc ; -struct smt_timer *timer ; +void smt_timer_stop(struct s_smc *smc, struct smt_timer *timer) { struct smt_timer **prev ; struct smt_timer *tm ; @@ -70,11 +59,8 @@ } } -void smt_timer_start(smc,timer,time,token) -struct s_smc *smc ; -struct smt_timer *timer ; -u_long time ; -u_long token ; +void smt_timer_start(struct s_smc *smc, struct smt_timer *timer, u_long time, + u_long token) { struct smt_timer **prev ; struct smt_timer *tm ; @@ -121,21 +107,17 @@ hwt_start(smc,smc->t.st_queue->tm_delta) ; } -void smt_force_irq(smc) -struct s_smc *smc ; +void smt_force_irq(struct s_smc *smc) { smt_timer_start(smc,&smc->t.st_fast,32L, EV_TOKEN(EVENT_SMT,SM_FAST)); } -void smt_timer_done(smc) -struct s_smc *smc ; +void smt_timer_done(struct s_smc *smc) { timer_done(smc,1) ; } -static void timer_done(smc,restart) -struct s_smc *smc ; -int restart ; +static void timer_done(struct s_smc *smc, int restart) { u_long delta ; struct smt_timer *tm ; @@ -171,3 +153,4 @@ if (restart && smc->t.st_queue) hwt_start(smc,smc->t.st_queue->tm_delta) ; } + diff -Nru a/drivers/net/skfp/srf.c b/drivers/net/skfp/srf.c --- a/drivers/net/skfp/srf.c 2004-06-17 14:49:49 -07:00 +++ b/drivers/net/skfp/srf.c 2004-06-17 14:49:49 -07:00 @@ -38,10 +38,10 @@ /* * function declarations */ -static void clear_all_rep() ; -static void clear_reported() ; -static void smt_send_srf() ; -static struct s_srf_evc *smt_get_evc() ; +static void clear_all_rep(struct s_smc *smc); +static void clear_reported(struct s_smc *smc); +static void smt_send_srf(struct s_smc *smc); +static struct s_srf_evc *smt_get_evc(struct s_smc *smc, int code, int index); #define MAX_EVCS (sizeof(smc->evcs)/sizeof(smc->evcs[0])) @@ -69,8 +69,7 @@ #define MAX_INIT_EVC (sizeof(evc_inits)/sizeof(evc_inits[0])) -void smt_init_evc(smc) -struct s_smc *smc ; +void smt_init_evc(struct s_smc *smc) { struct s_srf_evc *evc ; const struct evc_init *init ; @@ -159,10 +158,7 @@ smc->srf.sr_state = SR0_WAIT ; } -static struct s_srf_evc *smt_get_evc(smc,code,index) -struct s_smc *smc ; -int code ; -int index ; +static struct s_srf_evc *smt_get_evc(struct s_smc *smc, int code, int index) { int i ; struct s_srf_evc *evc ; @@ -188,11 +184,7 @@ } ; #endif -void smt_srf_event(smc,code,index,cond) -struct s_smc *smc ; -int code ; -int index ; -int cond ; +void smt_srf_event(struct s_smc *smc, int code, int index, int cond) { struct s_srf_evc *evc ; int cond_asserted = 0 ; @@ -340,8 +332,7 @@ } } -static void clear_all_rep(smc) -struct s_smc *smc ; +static void clear_all_rep(struct s_smc *smc) { struct s_srf_evc *evc ; int i ; @@ -354,8 +345,7 @@ smc->srf.any_report = FALSE ; } -static void clear_reported(smc) -struct s_smc *smc ; +static void clear_reported(struct s_smc *smc) { struct s_srf_evc *evc ; int i ; @@ -375,13 +365,10 @@ } } -extern SMbuf *smt_build_frame() ; - /* * build and send SMT SRF frame */ -static void smt_send_srf(smc) -struct s_smc *smc ; +static void smt_send_srf(struct s_smc *smc) { struct smt_header *smt ; @@ -439,3 +426,4 @@ #endif /* no BOOT */ #endif /* no SLIM_SMT */ + From davem@redhat.com Thu Jun 17 15:23:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:23:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMMngi018956 for ; Thu, 17 Jun 2004 15:23:10 -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 i5HMMde1002467; Thu, 17 Jun 2004 18:22:39 -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 i5HMMd012528; Thu, 17 Jun 2004 18:22:39 -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 i5HMMKZf021795; Thu, 17 Jun 2004 18:22:21 -0400 Date: Thu, 17 Jun 2004 15:22:16 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-Id: <20040617152216.00a5cec9.davem@redhat.com> In-Reply-To: <20040617213130.GB14089@gondor.apana.org.au> References: <20040616202341.GD29781@ms2.inr.ac.ru> <20040617105843.314dfe30.davem@redhat.com> <20040617213130.GB14089@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6087 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: 600 Lines: 16 On Fri, 18 Jun 2004 07:31:30 +1000 Herbert Xu wrote: > On Thu, Jun 17, 2004 at 10:58:43AM -0700, David S. Miller wrote: > > > > Do you see what xfrm_get_mss() does? It calls into x->type->get_max_size() > > and this is where ESP reports this kind of thing (re: block padding). > > Yes I know. But this is only used in TCP currently. Right. I'm sorry, is someone trying to do NFS/UDP over IPSEC? My condolences. :-) More seriously, it is a fringe case. We do need to handle it, but it is no accident that there haven't been very many folks complaining about it. From davem@redhat.com Thu Jun 17 15:29:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:29:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMTrgi019372 for ; Thu, 17 Jun 2004 15:29:54 -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 i5HMTie1004043; Thu, 17 Jun 2004 18:29:44 -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 i5HMTi014019; Thu, 17 Jun 2004 18:29:44 -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 i5HMTP9S023750; Thu, 17 Jun 2004 18:29:26 -0400 Date: Thu, 17 Jun 2004 15:29:21 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-Id: <20040617152921.730892c7.davem@redhat.com> In-Reply-To: <20040617213832.GC14089@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6088 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: 1600 Lines: 39 On Fri, 18 Jun 2004 07:38:32 +1000 Herbert Xu wrote: > Suppose that the MTU of 192.168.0.1 is 1500, and that the calculated MTU > for the bundle is 1430. > > If there is a host 10.10.10.10 on the Internet or behind some sort > a VPN where the path from 192.168.0.1 to it has an MTU of 1200, > then by sending a 1430-byte packet to 10.10.10.10 from 192.168.0.2, > we will get back an ICMP packet saying that the largest MTU for > 192.168.0.2-10.10.10.10 is 1200. > > This will be successfully stored in the route entry. But the route > entry's MTU is not used at all since the MTU of the bundle is deduced > from the MTU of the path, 192.168.0.1. So we'll continue to send large > packets to 10.10.10.10. This is what Alexey is talking about. When we send a packet out for an IPSEC rule, we have to remember the inner (per-transform pre-tunnel) IP addresses (keyed by outer IP address and ESP/AH spi) in order to get the ICMP PMTU messages handled correctly. We don't do this right now, it's difficult and complicated work. Tunnels are where do absolutely the wrong thing right now and PMTU does not work. What happens in your example is: PACKET transformed to --> [new IP hdr, ESP][Transformed PACKET] ICMP's come back addressed to the IP address in "new IP hdr" above. We need a way to go from that, plus the ESP spi, to the inner transformed IP header information. That is the missing link, and what we're not doing now. It's an issue not specific to making the gateway be the sender of the packet, it's an issue with tunnels in all cases currently. From shemminger@osdl.org Thu Jun 17 15:56:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:56:17 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMuCgi020267 for ; Thu, 17 Jun 2004 15:56:14 -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 i5HMu0r02921; Thu, 17 Jun 2004 15:56:00 -0700 Date: Thu, 17 Jun 2004 15:55:59 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: lartc@mailman.ds9a.nl, netdev@oss.sgi.com Subject: [PATCH] (2/4) delay scheduler - retry if requeue fails Message-Id: <20040617155559.5aeba553@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: 6090 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: 1312 Lines: 47 If delay scheduler decides not to send the packet right away, it requeues it. If the requeue fails, it should go and look again rather than waking up prematurely. Same patch should apply to both 2.6 and 2.4 Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_delay.c b/net/sched/sch_delay.c --- a/net/sched/sch_delay.c 2004-06-17 15:19:07 -07:00 +++ b/net/sched/sch_delay.c 2004-06-17 15:19:07 -07:00 @@ -104,8 +104,10 @@ static struct sk_buff *dly_dequeue(struct Qdisc *sch) { struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct sk_buff *skb = q->qdisc->dequeue(q->qdisc); + struct sk_buff *skb; + retry: + skb = q->qdisc->dequeue(q->qdisc); if (skb) { struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; psched_time_t now; @@ -120,6 +122,12 @@ return skb; } + if (q->qdisc->ops->requeue(skb, q->qdisc) != NET_XMIT_SUCCESS) { + sch->q.qlen--; + sch->stats.drops++; + goto retry; + } + if (!netif_queue_stopped(sch->dev)) { long delay = PSCHED_US2JIFFIE(diff); if (delay <= 0) @@ -127,10 +135,6 @@ mod_timer(&q->timer, jiffies+delay); } - if (q->qdisc->ops->requeue(skb, q->qdisc) != NET_XMIT_SUCCESS) { - sch->q.qlen--; - sch->stats.drops++; - } sch->flags |= TCQ_F_THROTTLED; } return NULL; From shemminger@osdl.org Thu Jun 17 15:56:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:56:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMu8gi020266 for ; Thu, 17 Jun 2004 15:56:08 -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 i5HMtur02917; Thu, 17 Jun 2004 15:55:56 -0700 Date: Thu, 17 Jun 2004 15:55:56 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [PATCH] (1/4) delay scheduler enqueue always succeeds. Message-Id: <20040617155556.5f53dff0@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: 6089 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: 490 Lines: 17 If underlying fifo enqueue fails, return the status not 0. Same patch should apply to both 2.6 and 2.4 Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_delay.c b/net/sched/sch_delay.c --- a/net/sched/sch_delay.c 2004-06-17 15:13:15 -07:00 +++ b/net/sched/sch_delay.c 2004-06-17 15:13:15 -07:00 @@ -69,7 +69,7 @@ sch->stats.bytes += skb->len; sch->stats.packets++; } - return 0; + return ret; } /* Requeue packets but don't change time stamp */ From shemminger@osdl.org Thu Jun 17 15:56:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:56:21 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMuGgi020274 for ; Thu, 17 Jun 2004 15:56: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 i5HMu3r02941; Thu, 17 Jun 2004 15:56:03 -0700 Date: Thu, 17 Jun 2004 15:56:03 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: "Dabney, Nathanx T" , "Venkatesan, Ganesh" , "Glick, Kevin" , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [PATCH] (3/4) delay scheduler race with device stopped Message-Id: <20040617155603.0651081c@dell_ss3.pdx.osdl.net> In-Reply-To: <58D550446979A646A05649BF9EAF113AA2E995@orsmsx407> References: <58D550446979A646A05649BF9EAF113AA2E995@orsmsx407> 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: 6092 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: 1376 Lines: 44 The delay scheduler dequeue routine has some code cut&pasted from the TBF scheduler that caused a race with E1000 when ring got full. It looks like net schedulers should never be calling netif_queue_stopped because the queue may get unstopped by interrrupt or receive soft irq (NAPI) which races with the dequeue in the transmit scheduler. Also, if requeuing the packet fails, it is probably because the queue became full by a racing enqueue. So the right thing to do is to go back and try again. Same patch should apply to both 2.6 and 2.4 Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_delay.c b/net/sched/sch_delay.c --- a/net/sched/sch_delay.c 2004-06-17 15:21:49 -07:00 +++ b/net/sched/sch_delay.c 2004-06-17 15:21:49 -07:00 @@ -111,7 +111,7 @@ if (skb) { struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; psched_time_t now; - long diff; + long diff, delay; PSCHED_GET_TIME(now); diff = q->latency - PSCHED_TDIFF(now, cb->queuetime); @@ -128,13 +128,10 @@ goto retry; } - if (!netif_queue_stopped(sch->dev)) { - long delay = PSCHED_US2JIFFIE(diff); - if (delay <= 0) - delay = 1; - mod_timer(&q->timer, jiffies+delay); - } - + delay = PSCHED_US2JIFFIE(diff); + if (delay <= 0) + delay = 1; + mod_timer(&q->timer, jiffies+delay); sch->flags |= TCQ_F_THROTTLED; } return NULL; From shemminger@osdl.org Thu Jun 17 15:56:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:56:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMuHgi020281 for ; Thu, 17 Jun 2004 15:56: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 i5HMu6r02949; Thu, 17 Jun 2004 15:56:06 -0700 Date: Thu, 17 Jun 2004 15:56:06 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [PATCH] (4/4) add loss option to network delay scheduler Message-Id: <20040617155606.558d8eb3@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: 6091 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: 1551 Lines: 61 This enhances the network simulation scheduler to do simple random loss. The loss parameter is a simple 32 bit value such that 0 means no loss, and 0xffffffff is always drop. I have a new version of the tc command which takes care of conversion from percent to this value. Same patch for 2.4 and 2.6 Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h --- a/include/linux/pkt_sched.h 2004-06-17 15:26:51 -07:00 +++ b/include/linux/pkt_sched.h 2004-06-17 15:26:51 -07:00 @@ -437,5 +437,6 @@ { __u32 latency; __u32 limit; -}; + __u32 loss; +}; #endif diff -Nru a/net/sched/sch_delay.c b/net/sched/sch_delay.c --- a/net/sched/sch_delay.c 2004-06-17 15:26:51 -07:00 +++ b/net/sched/sch_delay.c 2004-06-17 15:26:51 -07:00 @@ -40,6 +40,7 @@ struct dly_sched_data { u32 latency; u32 limit; + u32 loss; struct timer_list timer; struct Qdisc *qdisc; }; @@ -58,6 +59,12 @@ struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; int ret; + /* Random packet drop 0 => none, ~0 => all */ + if (q->loss >= net_random()) { + sch->stats.drops++; + return 0; /* lie about loss so TCP doesn't know */ + } + PSCHED_GET_TIME(cb->queuetime); /* Queue to underlying scheduler */ @@ -196,6 +203,7 @@ } else { q->latency = qopt->latency; q->limit = qopt->limit; + q->loss = qopt->loss; } return err; } @@ -232,6 +240,7 @@ qopt.latency = q->latency; qopt.limit = q->limit; + qopt.loss = q->loss; RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); From shemminger@osdl.org Thu Jun 17 15:57:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 15:58:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HMvlgi021242 for ; Thu, 17 Jun 2004 15:57: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 i5HMvZr03210; Thu, 17 Jun 2004 15:57:35 -0700 Date: Thu, 17 Jun 2004 15:57:35 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [PATCH] (1/4) delay scheduler enqueue always succeeds. Message-Id: <20040617155735.0edc56ff@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: 6093 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: 490 Lines: 17 If underlying fifo enqueue fails, return the status not 0. Same patch should apply to both 2.6 and 2.4 Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_delay.c b/net/sched/sch_delay.c --- a/net/sched/sch_delay.c 2004-06-17 15:13:15 -07:00 +++ b/net/sched/sch_delay.c 2004-06-17 15:13:15 -07:00 @@ -69,7 +69,7 @@ sch->stats.bytes += skb->len; sch->stats.packets++; } - return 0; + return ret; } /* Requeue packets but don't change time stamp */ From herbert@gondor.apana.org.au Thu Jun 17 16:10:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 16:10:12 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HNA4gi022262 for ; Thu, 17 Jun 2004 16:10: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 1Bb60Y-0003E4-00; Fri, 18 Jun 2004 09:09:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bb60U-0003q9-00; Fri, 18 Jun 2004 09:09:18 +1000 Date: Fri, 18 Jun 2004 09:09:18 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040617230918.GA14739@gondor.apana.org.au> References: <20040616202341.GD29781@ms2.inr.ac.ru> <20040617105843.314dfe30.davem@redhat.com> <20040617213130.GB14089@gondor.apana.org.au> <20040617152216.00a5cec9.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617152216.00a5cec9.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6095 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: 1099 Lines: 28 On Thu, Jun 17, 2004 at 03:22:16PM -0700, David S. Miller wrote: > > Right. I'm sorry, is someone trying to do NFS/UDP over IPSEC? > My condolences. :-) Nope, it breaks TCP as well. Whether you're TCP/UDP or whatever, you have to pass xfrm4_tunnel_check_size(). That function uses an incorrect derivation of the MTU, thus potentially blocking maximal packets from getting through. As I said before, this only strikes for certain device MTUs. So if you're having problems reproducing this, try setting your device MTU to 1480 (or 1480 + 8x for any integer x). > More seriously, it is a fringe case. We do need to handle it, > but it is no accident that there haven't been very > many folks complaining about it. I agree it's not a common problem. But the reason is not what you think it is :) It's because the common MTUs 1500, 1492 etc. are not of the form 1480 + 8x. 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 Thu Jun 17 16:09:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 16:09:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HN9ggi022167 for ; Thu, 17 Jun 2004 16:09:42 -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 i5HN9Ur05214; Thu, 17 Jun 2004 16:09:30 -0700 Date: Thu, 17 Jun 2004 16:09:30 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [RFT] netif_queue_stopped in TBF scheduler Message-Id: <20040617160930.729b35ad@dell_ss3.pdx.osdl.net> In-Reply-To: <20040617155603.0651081c@dell_ss3.pdx.osdl.net> References: <58D550446979A646A05649BF9EAF113AA2E995@orsmsx407> <20040617155603.0651081c@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: 6094 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: 1234 Lines: 42 There is a race between the device and scheduler if the scheduler looks at netif_queue_stopped. What can happen is that the device decides it is ready, just after the stopped check, and the scheduler decides it is throttled. The simple way is to just have the scheduler always dequeue and leave the flow control up to the driver and the core scheduling loop. Here is an untested fix for TBF scheduler based on the tested changes to the delay scheduler. diff -Nru a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c --- a/net/sched/sch_tbf.c 2004-06-17 15:56:47 -07:00 +++ b/net/sched/sch_tbf.c 2004-06-17 15:56:47 -07:00 @@ -201,7 +201,7 @@ if (skb) { psched_time_t now; - long toks; + long toks, delay; long ptoks = 0; unsigned int len = skb->len; @@ -229,14 +229,11 @@ return skb; } - if (!netif_queue_stopped(sch->dev)) { - long delay = PSCHED_US2JIFFIE(max_t(long, -toks, -ptoks)); + delay = PSCHED_US2JIFFIE(max_t(long, -toks, -ptoks)); + if (delay == 0) + delay = 1; - if (delay == 0) - delay = 1; - - mod_timer(&q->wd_timer, jiffies+delay); - } + mod_timer(&q->wd_timer, jiffies+delay); /* Maybe we have a shorter packet in the queue, which can be sent now. It sounds cool, From herbert@gondor.apana.org.au Thu Jun 17 16:13:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 16:13:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HNDMgi022860 for ; Thu, 17 Jun 2004 16:13: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 1Bb63m-0003HW-00; Fri, 18 Jun 2004 09:12:42 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bb63l-0003qo-00; Fri, 18 Jun 2004 09:12:41 +1000 Date: Fri, 18 Jun 2004 09:12:41 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040617231241.GB14739@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> <20040617152921.730892c7.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617152921.730892c7.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6096 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: 1888 Lines: 42 On Thu, Jun 17, 2004 at 03:29:21PM -0700, David S. Miller wrote: > On Fri, 18 Jun 2004 07:38:32 +1000 > Herbert Xu wrote: > > > Suppose that the MTU of 192.168.0.1 is 1500, and that the calculated MTU > > for the bundle is 1430. > > > > If there is a host 10.10.10.10 on the Internet or behind some sort > > a VPN where the path from 192.168.0.1 to it has an MTU of 1200, > > then by sending a 1430-byte packet to 10.10.10.10 from 192.168.0.2, > > we will get back an ICMP packet saying that the largest MTU for > > 192.168.0.2-10.10.10.10 is 1200. > > > > This will be successfully stored in the route entry. But the route > > entry's MTU is not used at all since the MTU of the bundle is deduced > > from the MTU of the path, 192.168.0.1. So we'll continue to send large > > packets to 10.10.10.10. > > This is what Alexey is talking about. When we send a packet out for > an IPSEC rule, we have to remember the inner (per-transform pre-tunnel) > IP addresses (keyed by outer IP address and ESP/AH spi) in order to get > the ICMP PMTU messages handled correctly. We don't do this right now, > it's difficult and complicated work. Right, that's *what* Alexey is talking about. But it's *not* what I'm talking about :) In my case, the ICMP message is not coming from the remote IPsec gateway or a router in front of it. It's coming from a host behind it. So the original IP header is in the ICMP message, in the clear. > It's an issue not specific to making the gateway be the sender of > the packet, it's an issue with tunnels in all cases currently. Correct. But before we get to that, let's fix the simple case 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 davem@redhat.com Thu Jun 17 16:14:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 16:14:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HNEcgi023188 for ; Thu, 17 Jun 2004 16:14:39 -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 i5HNEQe1015397; Thu, 17 Jun 2004 19:14:26 -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 i5HNEQ026661; Thu, 17 Jun 2004 19:14: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 i5HNE8Rg005972; Thu, 17 Jun 2004 19:14:08 -0400 Date: Thu, 17 Jun 2004 16:14:03 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-Id: <20040617161403.2d0ee598.davem@redhat.com> In-Reply-To: <20040617231241.GB14739@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> <20040617152921.730892c7.davem@redhat.com> <20040617231241.GB14739@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6097 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: 401 Lines: 10 On Fri, 18 Jun 2004 09:12:41 +1000 Herbert Xu wrote: > In my case, the ICMP message is not coming from the remote IPsec gateway > or a router in front of it. It's coming from a host behind it. So > the original IP header is in the ICMP message, in the clear. Remote gateway is supposed to encapsulate the ICMP message and send it back to the other gateway isn't it? From herbert@gondor.apana.org.au Thu Jun 17 16:19:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 16:19:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HNJegi026673 for ; Thu, 17 Jun 2004 16:19: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 1Bb69l-0003KQ-00; Fri, 18 Jun 2004 09:18:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bb69j-0003rw-00; Fri, 18 Jun 2004 09:18:51 +1000 Date: Fri, 18 Jun 2004 09:18:51 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040617231851.GA14861@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> <20040617152921.730892c7.davem@redhat.com> <20040617231241.GB14739@gondor.apana.org.au> <20040617161403.2d0ee598.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617161403.2d0ee598.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6098 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: 804 Lines: 18 On Thu, Jun 17, 2004 at 04:14:03PM -0700, David S. Miller wrote: > On Fri, 18 Jun 2004 09:12:41 +1000 > Herbert Xu wrote: > > > In my case, the ICMP message is not coming from the remote IPsec gateway > > or a router in front of it. It's coming from a host behind it. So > > the original IP header is in the ICMP message, in the clear. > > Remote gateway is supposed to encapsulate the ICMP message and send it > back to the other gateway isn't it? We are the other gateway :) Yes, I'm talking about what happens to that ICMP message once we decapsulate 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 ak@suse.de Thu Jun 17 19:32:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 19:32:06 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5I2Vxgi032440 for ; Thu, 17 Jun 2004 19:32:02 -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 64045734D47; Fri, 18 Jun 2004 04:31:53 +0200 (CEST) Date: Fri, 18 Jun 2004 04:31:51 +0200 From: Andi Kleen To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] Add /proc/net/tcp_listen Message-Id: <20040618043151.0483c158.ak@suse.de> 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: 6100 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: 8443 Lines: 283 This patch adds a /proc/net/tcp_listen. This is a performance optimization for slpd from openslp implementing the SLP protocol. A slpd regularly needs to check the LISTEN sockets on the local system to announce the services provided by them on the network. Problem is that reading /proc/net/tcp can be extremly slow, because it requires to lock/unlock hundred thousands of rwlocks. On some architectures (especially IA64 and PPC64) read_unlock seems to be quite slow and a simple cat /proc/net/tcp on a box with only a few sockets open can take over a second of systime. Doing this will also disturb network traffic severly (it makes actually a noticeable difference in SpecWeb) For slpd this problem can be avoided completely because it only cares about LISTEN sockets and the LISTEN hash table is much smaller and can be read much cheaper. For that this patch adds a new /proc/net/tcp_listen file that only lists LISTEN sockets. There were some proposals to make /proc/net/tcp faster too (like checking the hash bucket head first before getting the lock), but they are still all far slower than this. The patch reuses the existing infrastructure and doesn't add much bloat. Please consider merging. -Andi diff -u linux-2.6.7-work/include/net/tcp.h-TCPPROC linux-2.6.7-work/include/net/tcp.h --- linux-2.6.7-work/include/net/tcp.h-TCPPROC 2004-06-16 12:23:41.000000000 +0200 +++ linux-2.6.7-work/include/net/tcp.h 2004-06-18 04:23:40.000000000 +0200 @@ -2096,7 +2096,10 @@ struct module *owner; char *name; sa_family_t family; + void * (*seq_start)(struct seq_file *seq, loff_t *pos); int (*seq_show) (struct seq_file *m, void *v); + void * (*seq_next)(struct seq_file *seq, void *v, loff_t *pos); + struct file_operations *seq_fops; }; @@ -2111,6 +2114,11 @@ extern int tcp_proc_register(struct tcp_seq_afinfo *afinfo); extern void tcp_proc_unregister(struct tcp_seq_afinfo *afinfo); +extern void *tcp_seq_start(struct seq_file *seq, loff_t *pos); +extern void *tcp_listen_seq_start(struct seq_file *seq, loff_t *pos); +extern void *tcp_seq_next(struct seq_file *seq, void *v, loff_t *pos); +extern void *tcp_listen_seq_next(struct seq_file *seq, void *v, loff_t *pos); + /* TCP Westwood functions and constants */ #define TCP_WESTWOOD_INIT_RTT (20*HZ) /* maybe too conservative?! */ diff -u linux-2.6.7-work/net/ipv4/tcp_ipv4.c-TCPPROC linux-2.6.7-work/net/ipv4/tcp_ipv4.c --- linux-2.6.7-work/net/ipv4/tcp_ipv4.c-TCPPROC 2004-06-16 12:23:45.000000000 +0200 +++ linux-2.6.7-work/net/ipv4/tcp_ipv4.c 2004-06-18 04:20:13.000000000 +0200 @@ -2137,7 +2137,7 @@ hlist_entry(tw->tw_node.next, typeof(*tw), tw_node) : NULL; } -static void *listening_get_next(struct seq_file *seq, void *cur) +static void *listening_get_next(struct seq_file *seq, void *cur, int noopenreq) { struct tcp_opt *tp; struct hlist_node *node; @@ -2183,7 +2183,7 @@ } tp = tcp_sk(sk); read_lock_bh(&tp->syn_wait_lock); - if (tp->listen_opt && tp->listen_opt->qlen) { + if (!noopenreq && tp->listen_opt && tp->listen_opt->qlen) { st->uid = sock_i_uid(sk); st->syn_wait_sk = sk; st->state = TCP_SEQ_STATE_OPENREQ; @@ -2201,12 +2201,12 @@ return cur; } -static void *listening_get_idx(struct seq_file *seq, loff_t *pos) +static void *listening_get_idx(struct seq_file *seq, loff_t *pos, int noopenreq) { - void *rc = listening_get_next(seq, NULL); + void *rc = listening_get_next(seq, NULL, noopenreq); while (rc && *pos) { - rc = listening_get_next(seq, rc); + rc = listening_get_next(seq, rc, noopenreq); --*pos; } return rc; @@ -2303,40 +2303,54 @@ return rc; } -static void *tcp_get_idx(struct seq_file *seq, loff_t pos) +static void *tcp_get_idx(struct seq_file *seq, loff_t pos, int listenonly) { void *rc; struct tcp_iter_state* st = seq->private; tcp_listen_lock(); st->state = TCP_SEQ_STATE_LISTENING; - rc = listening_get_idx(seq, &pos); + rc = listening_get_idx(seq, &pos, listenonly); if (!rc) { - tcp_listen_unlock(); - local_bh_disable(); - st->state = TCP_SEQ_STATE_ESTABLISHED; - rc = established_get_idx(seq, pos); + if (!listenonly) { + tcp_listen_unlock(); + local_bh_disable(); + st->state = TCP_SEQ_STATE_ESTABLISHED; + rc = established_get_idx(seq, pos); + } } return rc; } -static void *tcp_seq_start(struct seq_file *seq, loff_t *pos) +void *tcp_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct tcp_iter_state* st = seq->private; + st->state = TCP_SEQ_STATE_LISTENING; + st->num = 0; + return *pos ? tcp_get_idx(seq, *pos - 1, 0) : SEQ_START_TOKEN; +} + +EXPORT_SYMBOL(tcp_seq_start); + +void *tcp_listen_seq_start(struct seq_file *seq, loff_t *pos) { struct tcp_iter_state* st = seq->private; st->state = TCP_SEQ_STATE_LISTENING; st->num = 0; - return *pos ? tcp_get_idx(seq, *pos - 1) : SEQ_START_TOKEN; + return *pos ? tcp_get_idx(seq, *pos - 1, 1) : SEQ_START_TOKEN; } -static void *tcp_seq_next(struct seq_file *seq, void *v, loff_t *pos) +EXPORT_SYMBOL(tcp_listen_seq_start); + +void *tcp_seq_next(struct seq_file *seq, void *v, loff_t *pos) { void *rc = NULL; struct tcp_iter_state* st; if (v == SEQ_START_TOKEN) { - rc = tcp_get_idx(seq, 0); + rc = tcp_get_idx(seq, 0, 0); goto out; } st = seq->private; @@ -2344,7 +2358,7 @@ switch (st->state) { case TCP_SEQ_STATE_OPENREQ: case TCP_SEQ_STATE_LISTENING: - rc = listening_get_next(seq, v); + rc = listening_get_next(seq, v, 0); if (!rc) { tcp_listen_unlock(); local_bh_disable(); @@ -2362,6 +2376,27 @@ return rc; } +EXPORT_SYMBOL(tcp_seq_next); + +void *tcp_listen_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + void *rc = NULL; + struct tcp_iter_state* st; + + if (v == SEQ_START_TOKEN) { + rc = tcp_get_idx(seq, 0, 1); + goto out; + } + st = seq->private; + rc = listening_get_next(seq, v, 1); + +out: + ++*pos; + return rc; +} + +EXPORT_SYMBOL(tcp_listen_seq_next); + static void tcp_seq_stop(struct seq_file *seq, void *v) { struct tcp_iter_state* st = seq->private; @@ -2400,8 +2435,8 @@ return -ENOMEM; memset(s, 0, sizeof(*s)); s->family = afinfo->family; - s->seq_ops.start = tcp_seq_start; - s->seq_ops.next = tcp_seq_next; + s->seq_ops.start = afinfo->seq_start; + s->seq_ops.next = afinfo->seq_next; s->seq_ops.show = afinfo->seq_show; s->seq_ops.stop = tcp_seq_stop; @@ -2570,18 +2605,36 @@ .owner = THIS_MODULE, .name = "tcp", .family = AF_INET, + .seq_start = tcp_seq_start, .seq_show = tcp4_seq_show, + .seq_next = tcp_seq_next, .seq_fops = &tcp4_seq_fops, }; +static struct file_operations tcp4_listen_seq_fops; +static struct tcp_seq_afinfo tcp4_listen_seq_afinfo = { + .owner = THIS_MODULE, + .name = "tcp_listen", + .family = AF_INET, + .seq_start = tcp_listen_seq_start, + .seq_show = tcp4_seq_show, + .seq_next = tcp_listen_seq_next, + .seq_fops = &tcp4_listen_seq_fops, +}; + + int __init tcp4_proc_init(void) { - return tcp_proc_register(&tcp4_seq_afinfo); + int err = tcp_proc_register(&tcp4_seq_afinfo); + if (err) + return err; + return tcp_proc_register(&tcp4_listen_seq_afinfo); } void tcp4_proc_exit(void) { tcp_proc_unregister(&tcp4_seq_afinfo); + tcp_proc_unregister(&tcp4_listen_seq_afinfo); } #endif /* CONFIG_PROC_FS */ diff -u linux-2.6.7-work/net/ipv6/tcp_ipv6.c-TCPPROC linux-2.6.7-work/net/ipv6/tcp_ipv6.c --- linux-2.6.7-work/net/ipv6/tcp_ipv6.c-TCPPROC 2004-06-16 12:23:45.000000000 +0200 +++ linux-2.6.7-work/net/ipv6/tcp_ipv6.c 2004-06-18 04:23:35.000000000 +0200 @@ -2066,18 +2066,35 @@ .owner = THIS_MODULE, .name = "tcp6", .family = AF_INET6, + .seq_start = tcp_seq_start, + .seq_next = tcp_seq_next, .seq_show = tcp6_seq_show, .seq_fops = &tcp6_seq_fops, }; +static struct file_operations tcp6_listen_seq_fops; +static struct tcp_seq_afinfo tcp6_listen_seq_afinfo = { + .owner = THIS_MODULE, + .name = "tcp6_listen", + .family = AF_INET6, + .seq_start = tcp_listen_seq_start, + .seq_next = tcp_listen_seq_next, + .seq_show = tcp6_seq_show, + .seq_fops = &tcp6_listen_seq_fops, +}; + int __init tcp6_proc_init(void) { - return tcp_proc_register(&tcp6_seq_afinfo); + int err = tcp_proc_register(&tcp6_seq_afinfo); + if (err) + return err; + return tcp_proc_register(&tcp6_listen_seq_afinfo); } void tcp6_proc_exit(void) { tcp_proc_unregister(&tcp6_seq_afinfo); + tcp_proc_unregister(&tcp6_listen_seq_afinfo); } #endif From yoshfuji@linux-ipv6.org Thu Jun 17 20:00:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 20:00:20 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5I30Igi001175 for ; Thu, 17 Jun 2004 20:00:18 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 2F8AA33CE5; Fri, 18 Jun 2004 12:01:16 +0900 (JST) Date: Fri, 18 Jun 2004 12:01:15 +0900 (JST) Message-Id: <20040618.120115.21661713.yoshfuji@linux-ipv6.org> To: ak@suse.de Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Add /proc/net/tcp_listen From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040618043151.0483c158.ak@suse.de> References: <20040618043151.0483c158.ak@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: 6101 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: 710 Lines: 24 In article <20040618043151.0483c158.ak@suse.de> (at Fri, 18 Jun 2004 04:31:51 +0200), Andi Kleen says: > int __init tcp4_proc_init(void) > { > - return tcp_proc_register(&tcp4_seq_afinfo); > + int err = tcp_proc_register(&tcp4_seq_afinfo); > + if (err) > + return err; > + return tcp_proc_register(&tcp4_listen_seq_afinfo); > } > > void tcp4_proc_exit(void) > { > tcp_proc_unregister(&tcp4_seq_afinfo); > + tcp_proc_unregister(&tcp4_listen_seq_afinfo); > } > #endif /* CONFIG_PROC_FS */ > If you register A then B, it is better to unregister B then A (symmetric). Yes, it does not matter in this case, but it is better coding style since there often are dependencies. --yoshfuji From davem@redhat.com Thu Jun 17 20:39:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 20:39:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5I3dbgi006460 for ; Thu, 17 Jun 2004 20:39:37 -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 i5I3dae1016514; Thu, 17 Jun 2004 23:39: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 i5I3da023717; Thu, 17 Jun 2004 23:39: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 i5I3dI0B026033; Thu, 17 Jun 2004 23:39:18 -0400 Date: Thu, 17 Jun 2004 20:39:09 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Add /proc/net/tcp_listen Message-Id: <20040617203909.1e7f7f9c.davem@redhat.com> In-Reply-To: <20040618043151.0483c158.ak@suse.de> References: <20040618043151.0483c158.ak@suse.de> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6103 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: 219 Lines: 6 Use netlink tcp_diag. It's built specifically for this. Just pass in the suitable fuilter, state == TCP_LISTEN. inetd and tcpd had support added, so adding support for this openslp thing should be similarly trivial. From jgarzik@pobox.com Thu Jun 17 22:32:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Jun 2004 22:32: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.12.10/8.12.9) with SMTP id i5I5Wlgi011311 for ; Thu, 17 Jun 2004 22:32:48 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb2GH-0005tk-6N; Thu, 17 Jun 2004 20:09:21 +0100 Message-ID: <40D1EC54.8000904@pobox.com> Date: Thu, 17 Jun 2004 15:09:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> In-Reply-To: <20040617185605.GA32216@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6106 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: 2294 Lines: 64 Jean Tourrilhes wrote: > On Thu, Jun 17, 2004 at 02:23:01PM -0400, Jeff Garzik wrote: > >>Jean Tourrilhes wrote: >> >>> As a matter of fact, I tried the strongly type approach you >>>advocate and find its kernel overhead not acceptable. Note that people >>>not using wireless have to suffer from this bloat, and wireless >>>extensions are used in embeeded platforms such as OpenAP, iPaq and >>>Zaurus where footprint matters. >> >>As you can see from the patch and header I have attached, there is >>_zero_ change to storage. No additional bloat. > > > I've never talked of driver bloat, which I don't really care > about. I'm talking of *kernel* bloat. And not about storage bloat, but > code bloat. Yes, I was referring to driver bloat not core kernel bloat. Nonetheless, the type-safe interface would not be larger, and very likely will be smaller. > When I designed the API, I did verify this carefully : > http://marc.theaimsgroup.com/?l=linux-kernel&m=100829443600986&w=2 This WAS a step forward, and this will help greatly in the implementation of wireless_ops. It's good stuff, but we are moving forward yet again :) >>Sorry, keeping compatibility with drivers outside the kernel is _not_ a >>priority here. Backward compatibility is how this cruft accumulated in >>the first place. >> >>Go ahead and assume that drivers outside the kernel will break. This is >>no different from vendor drivers -- if the driver is not in the kernel, >>it doesn't exist. > > > Jeff, this is not the way I work. For example, there are good > reasons why the Atheros driver is outside the kernel. Yes, but... that's the way the Linux kernel works. If a driver isn't in the kernel, it's the responsibility of the vendor to follow the changes in the kernel. It's not the kernel developer's responsibility to track random stuff posted on web pages. That's simply not scalable. I imagine this is another area where we must agree to disagree. Linux kernel development has always focused on in-tree drivers. Wireless traditionally has had a lot of drivers out-of-tree -- and being out of tree, we see what happens: vendors are encouraged to mixed binary-only drivers, multiple wireless stacks appears, and confusion reigned. It's now time for convergence :) Jeff From glen.turner@aarnet.edu.au Fri Jun 18 00:39:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 00:39:43 -0700 (PDT) Received: from clix.aarnet.edu.au (clix.aarnet.edu.au [192.94.63.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5I7dTgi019211 for ; Fri, 18 Jun 2004 00:39:30 -0700 Received: from [192.43.230.12] ([192.43.230.12]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id i5I7dOWo024082 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Jun 2004 17:39:25 +1000 Subject: Re: IPsec and Path MTU From: Glen Turner To: Michael Richardson Cc: netdev@oss.sgi.com In-Reply-To: <32703.1087311037@marajade.sandelman.ottawa.on.ca> References: <20040615124334.GA25164@gondor.apana.org.au> <32703.1087311037@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain Organization: Australian Academic and Research Network Message-Id: <1087544129.9044.27.camel@andromache> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 18 Jun 2004 17:05:29 +0930 Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6109 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: 1342 Lines: 40 On Wed, 2004-06-16 at 00:20, Michael Richardson wrote: > The pmtu WG is considering changing how PMTU is done. You may want to > look at draft-richardson-ipsec-fragment-XX.txt. This has not yet been > adopted as a WG draft, because nobody is sure which WG should adopt it:-) As well as longer term efforts you might note that altering the RFC1191 plateau table in the kernel to add 9000 would result in 10% less jumbo frames. The large absolute packet sizes are going to doom the plateau table approach at the next increase in MTU size. Hopefully Matt and your efforts we see deployment before then. Cheers, Glen diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c Fri Oct 24 13:23:50 2003 +++ b/net/ipv4/route.c Fri Oct 24 13:23:50 2003 @@ -1222,10 +1222,14 @@ /* * The last two values are not from the RFC but * are needed for AMPRnet AX.25 paths. + * The RFC has written before ethernet jumbo frames. + * Since these are the dominant large MTU we add them + * as using 8166 would lead to 10% more packets (a lot + * of CPU at 1Gbps). */ static unsigned short mtu_plateau[] = -{32000, 17914, 8166, 4352, 2002, 1492, 576, 296, 216, 128 }; +{32000, 17914, 9000, 8166, 4352, 2002, 1492, 576, 296, 216, 128 }; static __inline__ unsigned short guess_mtu(unsigned short old_mtu) { From random@72616e646f6d20323030342d30342d31360a.nosense.org Fri Jun 18 01:55:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 01:55:21 -0700 (PDT) Received: from nosense.org (225.cust3.sa.dsl.ozemail.com.au [210.84.226.225]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5I8tEgi006530 for ; Fri, 18 Jun 2004 01:55:16 -0700 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by nosense.org (Postfix) with SMTP id 18CCC3F0AD; Fri, 18 Jun 2004 18:25:06 +0930 (CST) Date: Fri, 18 Jun 2004 18:25:05 +0930 From: Mark Smith To: davem@redhat.com, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: [RFC PATCH] Change "local" route table preference from 0 to 3fff, to permit send-to-self policy routing Message-Id: <20040618182505.195d76ba.random@72616e646f6d20323030342d30342d31360a.nosense.org> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6111 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 8064 Lines: 178 Hi, Firstly, please accept my apologies for the size of this email. I've come up with a way of performing send-to-self routing, via two ethernet interfaces and a loopback (actually via a switch), using the policy routing engine. It is a bit fiddly to set up. I needed to be able to insert the policy routing rules before the "local" route table match. I've attached a (very) small patch to change the preference of the "local" route table from 0 to 3fff (16383), which is half of the value of the "default" route table preference. The 3fff value is mostly arbitrary, the assigned value isn't all that important as long as it is greater than zero, and leaves enough room for a number of preceeding policies. Here is how it is set up : (a) Assign IP addresses to the ethernet interfaces that are going to be used for the send-to-self traffic. In my example, I'm using 10.0.0.1 and 10.0.0.2 : [root@monte] # ip addr add 10.0.0.1/24 dev eth1 [root@monte] # ip addr add 10.0.0.2/24 dev eth2 [root@monte] # ip addr show dev eth1 9: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:40:33:23:c6:d2 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 inet 10.0.0.1/24 scope global eth1 inet6 fe80::240:33ff:fe23:c6d2/64 scope link valid_lft forever preferred_lft forever [root@monte] # ip addr show dev eth2 10: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:40:33:23:c2:1c brd ff:ff:ff:ff:ff:ff inet 192.168.2.2/24 brd 192.168.2.255 scope global eth2 inet 10.0.0.2/24 scope global eth2 inet6 fe80::240:33ff:fe23:c21c/64 scope link valid_lft forever preferred_lft forever [root@monte] # (b) Create two policies that match these IP addresses, and forward traffic towards them using custom route tables. These policies need to appear before the"local" route table match, hence the patch to change the "local" route table preference from 0 to 3fff. (partial output of"ip rule show" command to minimise confusion at this point - this stuff screwed with my head for a while when I was working it out): [root@monte] # ip rule add to 10.0.0.2 table 200 pref 200 [root@monte] # ip rule add to 10.0.0.1 table 201 pref 201 -- 200: from all to 10.0.0.2 lookup 200 201: from all to 10.0.0.1 lookup 201 -- (c) Create corresponding route tables, which specify which interface to use to get to the above IP addresses, and the source address to use when doing so : [root@monte] # ip route add 10.0.0.2 dev eth1 src 10.0.0.1 table 200 [root@monte] # ip route add 10.0.0.1 dev eth2 src 10.0.0.2 table 201 [root@monte] # ip route show table 200 10.0.0.2 dev eth1 scope link src 10.0.0.1 [root@monte] # ip route show table 201 10.0.0.1 dev eth2 scope link src 10.0.0.2 [root@monte] # At this point, any traffic sent towards 10.0.0.2 will leave the host via eth1, and any traffic towards 10.0.0.1 will leave the host via eth2, even though those addresses are assigned to local interfaces. The next step is to process this traffic when it comes into the host via eth2 for 10.0.0.2 and via eth1 for 10.0.0.1. (d) Create policies that match these IP addresses, on the specified incoming interface (which is the interface the address is assigned to), and use the "local" table for routing. Traffic processed by the "local" table will be processed by the host itself ie. passed up the network stack for local processing. These policies have to appear before both the "local" table policy and the previous policies that send the traffic out the ethernet interfaces. This ensures that traffic that enters the physical interfaces "jumps" over the policies that sent it out the physical interfaces in the first place. [root@monte] # ip rule add to 10.0.0.2 dev eth2 table local pref 100 [root@monte] # ip rule add to 10.0.0.1 dev eth1 table local pref 101 After this step, the policy ruleset will look as follows : [root@monte] # ip rule show 100: from all to 10.0.0.2 iif eth2 lookup local 101: from all to 10.0.0.1 iif eth1 lookup local 200: from all to 10.0.0.2 lookup 200 201: from all to 10.0.0.1 lookup 201 16383: from all lookup local 32766: from all lookup main 32767: from all lookup default (e) Finally, create static ARP entries for the IP addresses, specifying the MAC address of the interface the address is assigned to, and the interface that is going to be used to reach the address ie. the _other_ interface of the pair. [root@monte] # ip neigh add 10.0.0.2 dev eth1 lladdr 00:40:33:23:c2:1c [root@monte] # ip neigh add 10.0.0.1 dev eth2 lladdr 00:40:33:23:c6:d2 [root@monte] # ip neigh show 10.0.0.1 dev eth2 lladdr 00:40:33:23:c6:d2 nud permanent 10.0.0.2 dev eth1 lladdr 00:40:33:23:c2:1c nud permanent 192.168.0.1 dev eth0 lladdr 00:a0:cc:a2:6e:4d nud reachable [root@monte] # I don't know if this is completely necessary, I haven't played with the various ARP reply options available. By default, I didn't think I was seeing ARP replies from addresses assigned to the host itself, although I could have been a bit confused at this point. Creating static ARP entries seemed to fix that problem. Something I'll look into further, unless somebody can tell me that having a host reply its own ARP requests, even when received over a real interface, isn't possible at all. After all this configuration, here is a ping between the addresses, and the interface packet count statistics after the ping (edited very slightly, cutting-and-pasting from minicom screws up the formatting a bit, I used a serial console to avoid any network traffic influencing the counters): [root@monte] /root # ping -f 10.0.0.2 PING 10.0.0.2 (10.0.0.2): 56 data bytes . --- 10.0.0.2 ping statistics --- 796 packets transmitted, 795 packets received, 0% packet loss round-trip min/avg/max = 3.7/3.8/12.6 ms [root@monte] /root # ip -s link show dev eth1 9: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:40:33:23:c6:d2 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 78068 797 0 0 0 1 TX: bytes packets errors dropped carrier collsns 78386 801 0 0 0 0 [root@monte] /root # ip -s link show dev eth2 10: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:40:33:23:c2:1c brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 78068 797 0 0 0 1 TX: bytes packets errors dropped carrier collsns 78386 801 0 0 0 0 [root@monte] /root # The lights on the switch ports corresponding to eth1 and eth2 also blinked alot while running the above flood ping :-) The patch is as follows --- fib_rules.c.orig Thu Jun 17 21:31:46 2004 +++ fib_rules.c Thu Jun 17 21:32:43 2004 @@ -94,6 +94,7 @@ static struct fib_rule local_rule = { .r_next = &main_rule, .r_clntref = ATOMIC_INIT(2), + .r_preference = 0x3FFF, .r_table = RT_TABLE_LOCAL, .r_action = RTN_UNICAST, }; I'm hoping this patch could be applied. I don't think it effects the standard operation of the network stack, yet allows the above policy routing configuration to be implemented. Please note that I don't know much about kernel hacking, if there is a better way to change the "local" route table preference, I'm all ears. I'm interested in any comments, questions or constructive criticisms. For any follow up emails, please CC me as I'm not subscribed to the list. Thanks for reading this far :-) Regards, Mark. From david@dgreaves.com Fri Jun 18 02:08:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 02:08:50 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5I98jgi007594 for ; Fri, 18 Jun 2004 02:08:45 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 8FCA9E6A86; Fri, 18 Jun 2004 10:08:15 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27261-18; Fri, 18 Jun 2004 10:08:15 +0100 (BST) Received: from oak.dgreaves.com (modem-993.karuhiruhi.dialup.pol.co.uk [81.78.131.225]) by mail.ukfsn.org (Postfix) with ESMTP id 18B8FE6A94; Fri, 18 Jun 2004 10:08:14 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.126]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BbFOP-0004NG-Kt; Fri, 18 Jun 2004 10:10:37 +0100 Message-ID: <40D2B114.5020201@dgreaves.com> Date: Fri, 18 Jun 2004 10:08:36 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens Laas Cc: Stephen Hemminger , netdev@oss.sgi.com, ganesh.venkatesan@intel.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5I98jgi007594 X-archive-position: 6112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 3568 Lines: 115 Stephen, I applied your delay scheduler patch and some results appear below. Jens Laas wrote: > (04.06.16 kl.11:59) David Greaves skrev fljande till Stephen Hemminger: > > We have seen the same symptoms. (2.6.x + e1000) > > Our system is an SMP system. That might be whats triggering the problem. > Is your system UP or SMP ? UP > (Next reboot we will test running on only one CPU). > > We have tried with and without NAPI, both exhibit the same problem. Me too > We have tried different versions of e1000 without luck. Me too, 3 cards. (did I mention I have 2 machines with very similar specs (AMD/VIAKT600) and the other one works - actually, to be accurate, hasn't yet failed but hasn't yet run at full speed - and it has a higher CPU speed) > We have tried with 100Mb and gigabit switches. I'm now running two e1000's back to back over a piece of cat5... > > Make sure that flowcontrol is disabled on your switch (if it has it > implemented). ...so it's not that smart anymore ;) >> >> module parameters. > > > I believe following is recommended by driver developers: > TxDescriptors=256 RxDescriptors=256 FlowControl=0 XsumRX=0 Yes, I'm running with module defaults unless otherwise stated but I've tried that combo (to no effect) I'm speaking with Ganesh Venkatesan at intel about it. Ganesh you went off list - do you want to include Jens or maybe go back on-list? A simple failure case for me is : 'ping -s 1500 ' This doesn't cause the timout but doesn't succeed either. ping -f with standard packet size succeeds (slow rate though) and doesn't timeout. Using 8139 100Mbs card: 272384 packets transmitted, 272383 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/4.0 ms real 0m32.179s Using Pro/1000: 60992 packets transmitted, 60991 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.5/8.4 ms real 0m38.257s any ping with -s >1500 results in 100% packet loss. ============ From hereon down it's 2.6.7 with Stephen's recent delay scheduler patch This changed the behaviour. Now ping -s 1500 works but after that it gets lossy root@ash:~ # ping -s3000 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 3000 data bytes 3008 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=0.5 ms 3008 bytes from 10.0.1.1: icmp_seq=11 ttl=64 time=0.5 ms 3008 bytes from 10.0.1.1: icmp_seq=12 ttl=64 time=0.4 ms 3008 bytes from 10.0.1.1: icmp_seq=13 ttl=64 time=0.9 ms 3008 bytes from 10.0.1.1: icmp_seq=15 ttl=64 time=0.4 ms 3008 bytes from 10.0.1.1: icmp_seq=16 ttl=64 time=0.3 ms and now I'm seeing ping generate: Jun 18 09:41:57 ash kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 18 09:41:59 ash kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex ping -f now works for packet sizes up to -s 2952 (2 packets at mtu 1500) ping -f -s 2953 results in: PING 10.0.1.1 (10.0.1.1): 2953 data bytes ..............................ping: sendto: No buffer space available ping: wrote 10.0.1.1 2961 chars, ret=-1 .ping: sendto: No buffer space available nb. with the patch, between the same machines via an alternate pair of nics: root@ash:~ # ping -f -s29550 haze PING haze.dgreaves.com (10.0.0.88): 29550 data bytes . --- haze.dgreaves.com ping statistics --- 10592 packets transmitted, 10591 packets received, 0% packet loss round-trip min/avg/max = 5.4/5.5/83.5 ms Increasing Transmit Descriptors to 4096 avoids the No buffer space available with packet sizes up to -s65468 (still 100% failure though) I'm not sure that adds much now so I'll leave it until I get some more suggestions. HTH David From jens.laas@data.slu.se Fri Jun 18 03:27:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 03:28:12 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IARpgi014135 for ; Fri, 18 Jun 2004 03:27:52 -0700 Received: from jlaas2.data.slu.se (jlaas2.data.slu.se [130.238.98.68]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i5IARh8e009653; Fri, 18 Jun 2004 12:27:43 +0200 Date: Fri, 18 Jun 2004 12:27:43 +0200 (CEST) From: Jens Laas X-X-Sender: jensl@jlaas2.data.slu.se To: David Greaves cc: Jens Laas , Stephen Hemminger , netdev@oss.sgi.com, ganesh.venkatesan@intel.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler In-Reply-To: <40D2B114.5020201@dgreaves.com> Message-ID: References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> <40D2B114.5020201@dgreaves.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-271200117-1087554463=:1089" X-archive-position: 6114 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jens.laas@data.slu.se Precedence: bulk X-list: netdev Content-Length: 3929 Lines: 138 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-271200117-1087554463=:1089 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.slu.se id i5IARh8e009653 (04.06.18 kl.10:08) David Greaves skrev f=F6ljande till Jens Laas: > Stephen, I applied your delay scheduler patch and some results appear b= elow. > > Jens Laas wrote: > >> (04.06.16 kl.11:59) David Greaves skrev f=F6ljande till Stephen Hemmin= ger: >>=20 >> We have seen the same symptoms. (2.6.x + e1000) >>=20 >> Our system is an SMP system. That might be whats triggering the proble= m. >> Is your system UP or SMP ? > > UP Ok. This keeps getting stranger.. > >> (Next reboot we will test running on only one CPU). >>=20 >> We have tried with and without NAPI, both exhibit the same problem. > > Me too > >> We have tried different versions of e1000 without luck. > ... >> Make sure that flowcontrol is disabled on your switch (if it has it=20 >> implemented). > > ...so it's not that smart anymore ;) > >>>=20 >>> module parameters. >>=20 >>=20 >> I believe following is recommended by driver developers: >> TxDescriptors=3D256 RxDescriptors=3D256 FlowControl=3D0 XsumRX=3D0 > > Yes, I'm running with module defaults unless otherwise stated but I've = tried=20 > that combo (to no effect) No effect here either. FlowControl and XsumRX are known troublemakers. > > I'm speaking with Ganesh Venkatesan at intel about it. Ganesh you went = off=20 > list - do you want to include Jens or maybe go back on-list? If others run into this problem I'm sure they'll appreciate if its on=20 list. Since we have no idea what causes this (AFAIK) it may be a more general=20 problem than the device driver. > > A simple failure case for me is : 'ping -s 1500 ' > This doesn't cause the timout but doesn't succeed either. > > ping -f with standard packet size succeeds (slow rate though) and doesn= 't=20 > timeout. I dont see the ping problems at all. Unless you try to ping when the=20 interface has "hanged" ? > > Using 8139 100Mbs card: > 272384 packets transmitted, 272383 packets received, 0% packet loss > round-trip min/avg/max =3D 0.1/0.1/4.0 ms > real 0m32.179s > > Using Pro/1000: > 60992 packets transmitted, 60991 packets received, 0% packet loss > round-trip min/avg/max =3D 0.0/0.5/8.4 ms > real 0m38.257s > > any ping with -s >1500 results in 100% packet loss. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From hereon down it's 2.6.7 with Stephen's recent delay scheduler patch > > This changed the behaviour. This is strange unless you are actually using the delay scheduler ? Default is sch_generic (that is pfifo) that does not exhibit the problems= =20 correct by the patch. > 10592 packets transmitted, 10591 packets received, 0% packet loss > round-trip min/avg/max =3D 5.4/5.5/83.5 ms > > Increasing Transmit Descriptors to 4096 avoids the No buffer space avai= lable=20 > with packet sizes up to -s65468 (still 100% failure though) Increasing nr of buffers is not a way to fix the problem. I had hoped to hear something about this from Scott.. Cheers, Jens > > I'm not sure that adds much now so I'll leave it until I get some more=20 > suggestions. > > HTH > > David > ----------------------------------------------------------------------- 'This mail automatically becomes portable when carried.' ----------------------------------------------------------------------- Jens L=E5=E5s Email: jens.laas@data.slu= .se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrov=E4gen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN=20 ----------------------------------------------------------------------- --8323328-271200117-1087554463=:1089-- From herbert@gondor.apana.org.au Fri Jun 18 04:37:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 04:38:12 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IBbFgi021637 for ; Fri, 18 Jun 2004 04:37: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 1BbHf2-00081h-00; Fri, 18 Jun 2004 21:35:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BbHeo-00053Z-00; Fri, 18 Jun 2004 21:35:42 +1000 From: Herbert Xu To: vitalyvb@ukr.net (Vitaly V. Bursov) Subject: Re: linux-2.6.7 Equalizer Load-balancer. eql.c. local non-privileged DoS Cc: linux-kernel@vger.kernel.org, alan@redhat.com, davem@redhat.com, jgarzik@pobox.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040618115153.3ad2dc32.vitalyvb@ukr.net> X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.25-1-686-smp (i686)) Message-Id: Date: Fri, 18 Jun 2004 21:35:42 +1000 X-archive-position: 6115 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: 1069 Lines: 39 Vitaly V. Bursov wrote: > > there are multiple vulns in drivers/net/eql.c > > if there is no such device, dev_get_by_name returns NULL and everything dies. > Exploiting this is trivial. Thanks for the report. This patch should fix 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 -- ===== drivers/net/eql.c 1.13 vs edited ===== --- 1.13/drivers/net/eql.c 2004-06-05 01:50:36 +10:00 +++ edited/drivers/net/eql.c 2004-06-18 21:30:49 +10:00 @@ -497,6 +497,8 @@ slave_dev = dev_get_by_name(sc.slave_name); ret = -EINVAL; + if (!slave_dev) + return ret; spin_lock_bh(&eql->queue.lock); if (eql_is_slave(slave_dev)) { @@ -531,6 +533,8 @@ slave_dev = dev_get_by_name(sc.slave_name); ret = -EINVAL; + if (!slave_dev) + return ret; spin_lock_bh(&eql->queue.lock); if (eql_is_slave(slave_dev)) { From david@dgreaves.com Fri Jun 18 06:33:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 06:33:49 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IDXYgi029924 for ; Fri, 18 Jun 2004 06:33:35 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 8B435E6A9F; Fri, 18 Jun 2004 13:51:25 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07740-14; Fri, 18 Jun 2004 13:51:25 +0100 (BST) Received: from oak.dgreaves.com (modem-3504.putangitangi.dialup.pol.co.uk [81.78.205.176]) by mail.ukfsn.org (Postfix) with ESMTP id 50578E6A94; Fri, 18 Jun 2004 13:51:24 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.126]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BbIsO-0004au-L0; Fri, 18 Jun 2004 13:53:48 +0100 Message-ID: <40D2E563.7080302@dgreaves.com> Date: Fri, 18 Jun 2004 13:51:47 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens Laas Cc: Stephen Hemminger , netdev@oss.sgi.com, ganesh.venkatesan@intel.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> <40D2B114.5020201@dgreaves.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 2736 Lines: 81 New info: I booted into XP and the card works there - so it doesn't look like a simple hardware incompatibility. [I've got no real way to test the performance but cygwin's wget against apache1.3 on the linux box returns about 25M/s initially and then 15M/s sustained for 500Mb] Jens Laas wrote: >> >> I'm speaking with Ganesh Venkatesan at intel about it. Ganesh you >> went off list - do you want to include Jens or maybe go back on-list? > > > If others run into this problem I'm sure they'll appreciate if its on > list. > Since we have no idea what causes this (AFAIK) it may be a more > general problem than the device driver. I tend to agree - but I wasn't sure if this was the place and I'll do as I'm told ;) >> A simple failure case for me is : 'ping -s 1500 ' >> This doesn't cause the timout but doesn't succeed either. >> >> ping -f with standard packet size succeeds (slow rate though) and >> doesn't timeout. > > > > I dont see the ping problems at all. Unless you try to ping when the > interface has "hanged" ? thought that might be helpful. Ping with -s and -f seems to allow me to trigger errors and it seems a lot more debug-able than scp or nfs :) No all tests are when it's reset and 'clean' >> ============ >> From hereon down it's 2.6.7 with Stephen's recent delay scheduler patch >> >> This changed the behaviour. > > > > This is strange unless you are actually using the delay scheduler ? > Default is sch_generic (that is pfifo) that does not exhibit the > problems correct by the patch. I'll go back and double check in case I cocked up... (I noticed the e1000 module rebuild but you're right that's incidental) I've rebuilt the kernel and modules with and w/o patch and rebooted a few times and I can't reproduce that effect - sorry for the red herring. So after I reverted Stephens patch the results I reported are still reproducable w/o the patch. >> 10592 packets transmitted, 10591 packets received, 0% packet loss >> round-trip min/avg/max = 5.4/5.5/83.5 ms >> >> Increasing Transmit Descriptors to 4096 avoids the No buffer space >> available with packet sizes up to -s65468 (still 100% failure though) > > > Increasing nr of buffers is not a way to fix the problem. agreed - however in my ignorance of the deep behaviour I'm reporting things that affect behaviour in ways I don't expect. I expected it to take longer to run out of buffers - that didn't happen :) (Anyway, on retesting I find that this was wrong - I suspect the interface was down and I didn't notice) > > I had hoped to hear something about this from Scott.. I'm happy to hear from anyone - I don't have *that* long until my RMA option expires and I don't fancy keeping them as ornaments! David From ganesh.venkatesan@intel.com Fri Jun 18 07:41:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 07:41:06 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IEf0gi011198 for ; Fri, 18 Jun 2004 07:41:01 -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 i5IEgM5m016899; Fri, 18 Jun 2004 14:42:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5IEfcEu031772; Fri, 18 Jun 2004 14:41:54 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061807403407227 ; Fri, 18 Jun 2004 07:40:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 18 Jun 2004 07:40:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler Date: Fri, 18 Jun 2004 07:40:32 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E01767AF6@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler Thread-Index: AcRVMwkx20am0MoMQiOnzGHB5cCwQAADlDsA From: "Venkatesan, Ganesh" To: "David Greaves" , "Jens Laas" Cc: "Stephen Hemminger" , X-OriginalArrivalTime: 18 Jun 2004 14:40:34.0257 (UTC) FILETIME=[366D9410:01C45542] 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 i5IEf0gi011198 X-archive-position: 6119 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: 3456 Lines: 111 Jens/David: Did not mean to get off the list. For some reason, my subscription to netdev is not working (even after re-subscribing). So, I grabbed your message off of the archive. I am trying to recreate your failure scenario in our lab. In the meantime, please send me any new information you have on this issue. Thanks, ganesh ------------------------------------------------- Ganesh Venkatesan Network/Storage Division, Hillsboro, OR -----Original Message----- From: David Greaves [mailto:david@dgreaves.com] Sent: Friday, June 18, 2004 5:52 AM To: Jens Laas Cc: Stephen Hemminger; netdev@oss.sgi.com; Venkatesan, Ganesh Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler New info: I booted into XP and the card works there - so it doesn't look like a simple hardware incompatibility. [I've got no real way to test the performance but cygwin's wget against apache1.3 on the linux box returns about 25M/s initially and then 15M/s sustained for 500Mb] Jens Laas wrote: >> >> I'm speaking with Ganesh Venkatesan at intel about it. Ganesh you >> went off list - do you want to include Jens or maybe go back on-list? > > > If others run into this problem I'm sure they'll appreciate if its on > list. > Since we have no idea what causes this (AFAIK) it may be a more > general problem than the device driver. I tend to agree - but I wasn't sure if this was the place and I'll do as I'm told ;) >> A simple failure case for me is : 'ping -s 1500 ' >> This doesn't cause the timout but doesn't succeed either. >> >> ping -f with standard packet size succeeds (slow rate though) and >> doesn't timeout. > > > > I dont see the ping problems at all. Unless you try to ping when the > interface has "hanged" ? thought that might be helpful. Ping with -s and -f seems to allow me to trigger errors and it seems a lot more debug-able than scp or nfs :) No all tests are when it's reset and 'clean' >> ============ >> From hereon down it's 2.6.7 with Stephen's recent delay scheduler patch >> >> This changed the behaviour. > > > > This is strange unless you are actually using the delay scheduler ? > Default is sch_generic (that is pfifo) that does not exhibit the > problems correct by the patch. I'll go back and double check in case I cocked up... (I noticed the e1000 module rebuild but you're right that's incidental) I've rebuilt the kernel and modules with and w/o patch and rebooted a few times and I can't reproduce that effect - sorry for the red herring. So after I reverted Stephens patch the results I reported are still reproducable w/o the patch. >> 10592 packets transmitted, 10591 packets received, 0% packet loss >> round-trip min/avg/max = 5.4/5.5/83.5 ms >> >> Increasing Transmit Descriptors to 4096 avoids the No buffer space >> available with packet sizes up to -s65468 (still 100% failure though) > > > Increasing nr of buffers is not a way to fix the problem. agreed - however in my ignorance of the deep behaviour I'm reporting things that affect behaviour in ways I don't expect. I expected it to take longer to run out of buffers - that didn't happen :) (Anyway, on retesting I find that this was wrong - I suspect the interface was down and I didn't notice) > > I had hoped to hear something about this from Scott.. I'm happy to hear from anyone - I don't have *that* long until my RMA option expires and I don't fancy keeping them as ornaments! David From jgarzik@pobox.com Fri Jun 18 08:28:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 08:28:57 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IFSpgi016238 for ; Fri, 18 Jun 2004 08:28:52 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb2ei-0006KB-2v; Thu, 17 Jun 2004 20:34:36 +0100 Message-ID: <40D1F23E.9090307@pobox.com> Date: Thu, 17 Jun 2004 15:34:22 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: netdev@oss.sgi.com, Gertjan van Wingerde , sfeldma@pobox.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <40D1E24C.8090802@pobox.com> <20040617185815.GB32216@bougret.hpl.hp.com> <40D1EAD9.6090403@pobox.com> <20040617191338.GD32216@bougret.hpl.hp.com> In-Reply-To: <20040617191338.GD32216@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6121 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: 1797 Lines: 56 Jean Tourrilhes wrote: > On Thu, Jun 17, 2004 at 03:02:49PM -0400, Jeff Garzik wrote: > >>Jean Tourrilhes wrote: >> >>>On Thu, Jun 17, 2004 at 02:26:20PM -0400, Jeff Garzik wrote: >>> >>> >>>>Note that the above is only a first step. Through the standard Linux >>>>development process -- evolution -- each hook can be pared down to >>>>precisely what each call needs. The above allows for a quick transition >>>>of drivers, while keeping them working. >>>> >>>> Jeff >>> >>> >>> Have you looked at the patch I sent you ? In which way does it >>>fails to meet your need ? >> >> >>The three major problems I listed in a previous email are still >>present... > > > Are we talking of the same patch ? I'm talking of this patch : > http://marc.theaimsgroup.com/?l=linux-netdev&m=108749580004668&w=2 > I reattached the patch below. It's short enough. Your patch is half the job -- it allows development of a type-specific interface... but it does nothing to address the problems with the underlying type-opaque interface. The creation of the type-specific interface replaces the type-opaque interface, not layers on top of it. So while this patch may be useful in early development, it does not allow the direct exposure of core wireless code to the type-specific interfaces, and as such, it can paper over problems that would be immediately obviously if the type-specific interface were the only one to exist. >> Also there is a fourth -- WE doesn't work 100% when you have >>a 32-bit userland and a 64-bit kernel. > > > Since when ? What made you change your mind ? > Please check : > http://marc.theaimsgroup.com/?l=linux-netdev&m=107894322418086&w=2 The general API, yes. But most driver-private interfaces will fail miserably through 32/64-bit translation. Jeff From mdomsch@lists.us.dell.com Fri Jun 18 09:10:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 09:10:47 -0700 (PDT) Received: from lists.us.dell.com (linux.us.dell.com [143.166.224.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IGADgi022871 for ; Fri, 18 Jun 2004 09:10:14 -0700 Received: from lists.us.dell.com (localhost.localdomain [127.0.0.1]) by lists.us.dell.com (8.12.10/8.12.10/Dell.IT.3.31.03) with ESMTP id i5IGA18o020363; Fri, 18 Jun 2004 11:10:01 -0500 Received: (from mdomsch@localhost) by lists.us.dell.com (8.12.10/8.12.10/Submit) id i5IGA1ZM020361; Fri, 18 Jun 2004 11:10:01 -0500 Date: Fri, 18 Jun 2004 11:10:01 -0500 From: Matt Domsch To: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net Subject: RFC: [0/3] PPP MPPE module Message-ID: <20040618161001.GE19269@lists.us.dell.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 6122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev Content-Length: 1419 Lines: 48 --KuLpqunXa7jZSBt+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The pptpclient project at SourceForge has for several years maintained the PPP MPPE (Microsoft Point-to-Point Encryption) ppp compressor/decompressor module outside of the Linux kernel tree, as it has needed arc4 and sha1 crypto routines which were not in-kernel yet. As they now are, I'd like to submit this code for review, and when deemed ready, inclusion, into 2.6.x. MPPE is a requirement for connecting Linux clients to Linux and Microsoft PPTP (Point to Point Tunneling Protocol) servers. Following two emails each contain patches. 1) Add ppp_mppe.c file to drivers/net 2) minimal touches to Makefile, KConfig, ppp_generic.c, and include/linux/ppp-comp.h I've asked that the pptpclient-devel list be opened to posts by non-subscribers during this review period at least. Feedback welcome. Thanks, Matt --=20 Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com --KuLpqunXa7jZSBt+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA0xPZIavu95Lw/AkRAi/nAJ4q2VsUchBS0q8W3ph2urgnXDeGWACdG1UV JThHe9FACExvy1qLqAd6Vpc= =GGep -----END PGP SIGNATURE----- --KuLpqunXa7jZSBt+-- From mdomsch@lists.us.dell.com Fri Jun 18 09:12:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 09:13:35 -0700 (PDT) Received: from lists.us.dell.com (lists.us.dell.com [143.166.224.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IGCsgi023456 for ; Fri, 18 Jun 2004 09:12:55 -0700 Received: from lists.us.dell.com (localhost.localdomain [127.0.0.1]) by lists.us.dell.com (8.12.10/8.12.10/Dell.IT.3.31.03) with ESMTP id i5IGCg8o020623; Fri, 18 Jun 2004 11:12:42 -0500 Received: (from mdomsch@localhost) by lists.us.dell.com (8.12.10/8.12.10/Submit) id i5IGCgCM020621; Fri, 18 Jun 2004 11:12:42 -0500 Date: Fri, 18 Jun 2004 11:12:42 -0500 From: Matt Domsch To: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net Subject: RFC: [1/2] PPP MPPE module Message-ID: <20040618161242.GG19269@lists.us.dell.com> References: <20040618161001.GE19269@lists.us.dell.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NPukt5Otb9an/u20" Content-Disposition: inline In-Reply-To: <20040618161001.GE19269@lists.us.dell.com> User-Agent: Mutt/1.4.1i X-archive-position: 6123 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev Content-Length: 9190 Lines: 229 --NPukt5Otb9an/u20 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 18, 2004 at 11:10:01AM -0500, Matt Domsch wrote: > Following two emails each contain patches. Of course, that subject should have been [0,1,2/2], not of 3. > 2) minimal touches to Makefile, KConfig, ppp_generic.c, and > include/linux/ppp-comp.h --=20 Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com =3D=3D=3D=3D=3D drivers/net/Kconfig 1.75 vs edited =3D=3D=3D=3D=3D --- 1.75/drivers/net/Kconfig 2004-06-02 15:04:38 -05:00 +++ edited/drivers/net/Kconfig 2004-06-18 09:48:16 -05:00 @@ -2410,6 +2410,12 @@ module; it is called bsd_comp and will show up in the directory modules once you have said "make modules". If unsure, say N. =20 +config PPP_MPPE + tristate "PPP MPPE compression (encryption)" + depends on PPP + ---help--- + Support for the MPPE Encryption protocol. + config PPPOE tristate "PPP over Ethernet (EXPERIMENTAL)" depends on EXPERIMENTAL && PPP =3D=3D=3D=3D=3D drivers/net/Makefile 1.79 vs edited =3D=3D=3D=3D=3D --- 1.79/drivers/net/Makefile 2004-05-22 12:13:08 -05:00 +++ edited/drivers/net/Makefile 2004-06-18 10:22:41 -05:00 @@ -100,6 +100,7 @@ obj-$(CONFIG_PPP_SYNC_TTY) +=3D ppp_synctty.o obj-$(CONFIG_PPP_DEFLATE) +=3D ppp_deflate.o obj-$(CONFIG_PPP_BSDCOMP) +=3D bsd_comp.o +obj-$(CONFIG_PPP_MPPE) +=3D ppp_mppe.o obj-$(CONFIG_PPPOE) +=3D pppox.o pppoe.o =20 obj-$(CONFIG_SLIP) +=3D slip.o =3D=3D=3D=3D=3D drivers/net/ppp_generic.c 1.45 vs edited =3D=3D=3D=3D=3D --- 1.45/drivers/net/ppp_generic.c 2004-04-09 18:21:06 -05:00 +++ edited/drivers/net/ppp_generic.c 2004-06-18 09:47:10 -05:00 @@ -1066,8 +1066,15 @@ /* try to do packet compression */ if ((ppp->xstate & SC_COMP_RUN) && ppp->xc_state !=3D 0 && proto !=3D PPP_LCP && proto !=3D PPP_CCP) { - new_skb =3D alloc_skb(ppp->dev->mtu + ppp->dev->hard_header_len, - GFP_ATOMIC); + int new_skb_size =3D ppp->dev->mtu + ppp->dev->hard_header= _len; + int compressor_skb_size =3D ppp->dev->mtu + PPP_HDRLEN; + + if (ppp->xcomp->compress_proto =3D=3D CI_MPPE) { + /* CCP [must have] reduced MTU by MPPE_PAD. */ + new_skb_size +=3D MPPE_PAD; + compressor_skb_size +=3D MPPE_PAD; + } + new_skb =3D alloc_skb(new_skb_size, GFP_ATOMIC); if (new_skb =3D=3D 0) { printk(KERN_ERR "PPP: no memory (comp pkt)\n"); goto drop; @@ -1079,15 +1086,27 @@ /* compressor still expects A/C bytes in hdr */ len =3D ppp->xcomp->compress(ppp->xc_state, skb->data - 2, new_skb->data, skb->len + 2, - ppp->dev->mtu + PPP_HDRLEN); + compressor_skb_size); if (len > 0 && (ppp->flags & SC_CCP_UP)) { kfree_skb(skb); skb =3D new_skb; skb_put(skb, len); skb_pull(skb, 2); /* pull off A/C bytes */ - } else { + } else if (len =3D=3D 0) { /* didn't compress, or CCP not up yet */ kfree_skb(new_skb); + } else { + /* + * (len < 0) + * MPPE requires that we do not send unencrypted + * frames. The compressor will return -1 if we + * should drop the frame. We cannot simply test + * the compress_proto because MPPE and MPPC share + * the same number. + */ + printk(KERN_ERR "ppp: compressor dropped pkt\n"); + kfree_skb(new_skb); + goto drop; } } =20 @@ -1596,7 +1615,7 @@ goto err; =20 if (proto =3D=3D PPP_COMP) { - ns =3D dev_alloc_skb(ppp->mru + PPP_HDRLEN); + ns =3D dev_alloc_skb(ppp->mru + 128 + PPP_HDRLEN); if (ns =3D=3D 0) { printk(KERN_ERR "ppp_decompress_frame: no memory\n"); goto err; =3D=3D=3D=3D=3D include/linux/ppp-comp.h 1.4 vs edited =3D=3D=3D=3D=3D --- 1.4/include/linux/ppp-comp.h 2003-08-07 18:57:19 -05:00 +++ edited/include/linux/ppp-comp.h 2004-06-18 09:46:32 -05:00 @@ -191,6 +191,100 @@ #define DEFLATE_CHK_SEQUENCE 0 =20 /* + * Definitions for MPPE. + */ + +#define CI_MPPE 18 /* config option for MPPE */ +#define CILEN_MPPE 6 /* length of config option */ + +#define MPPE_PAD 8 /* MPPE growth per frame */ +#define MPPE_MAX_KEY_LEN 16 /* largest key length (128-bit) */ + +/* option bits for ccp_options.mppe */ +#define MPPE_OPT_40 0x01 /* 40 bit */ +#define MPPE_OPT_128 0x02 /* 128 bit */ +#define MPPE_OPT_STATEFUL 0x04 /* stateful mode */ +/* unsupported opts */ +#define MPPE_OPT_56 0x08 /* 56 bit */ +#define MPPE_OPT_MPPC 0x10 /* MPPC compression */ +#define MPPE_OPT_D 0x20 /* Unknown */ +#define MPPE_OPT_UNSUPPORTED (MPPE_OPT_56|MPPE_OPT_MPPC|MPPE_OPT_D) +#define MPPE_OPT_UNKNOWN 0x40 /* Bits !defined in RFC 3078 were s= et */ + +/* + * This is not nice ... the alternative is a bitfield struct though. + * And unfortunately, we cannot share the same bits for the option + * names above since C and H are the same bit. We could do a u_int32 + * but then we have to do a htonl() all the time and/or we still need + * to know which octet is which. + */ +#define MPPE_C_BIT 0x01 /* MPPC */ +#define MPPE_D_BIT 0x10 /* Obsolete, usage unknown */ +#define MPPE_L_BIT 0x20 /* 40-bit */ +#define MPPE_S_BIT 0x40 /* 128-bit */ +#define MPPE_M_BIT 0x80 /* 56-bit, not supported */ +#define MPPE_H_BIT 0x01 /* Stateless (in a different byte) = */ + +/* Does not include H bit; used for least significant octet only. */ +#define MPPE_ALL_BITS (MPPE_D_BIT|MPPE_L_BIT|MPPE_S_BIT|MPPE_M_BIT|MPPE_H_= BIT) + +/* Build a CI from mppe opts (see RFC 3078) */ +#define MPPE_OPTS_TO_CI(opts, ci) \ + do { \ + u_char *ptr =3D ci; /* u_char[4] */ \ + \ + /* H bit */ \ + if (opts & MPPE_OPT_STATEFUL) \ + *ptr++ =3D 0x0; \ + else \ + *ptr++ =3D MPPE_H_BIT; \ + *ptr++ =3D 0; \ + *ptr++ =3D 0; \ + \ + /* S,L bits */ \ + *ptr =3D 0; \ + if (opts & MPPE_OPT_128) \ + *ptr |=3D MPPE_S_BIT; \ + if (opts & MPPE_OPT_40) \ + *ptr |=3D MPPE_L_BIT; \ + /* M,D,C bits not supported */ \ + } while (/* CONSTCOND */ 0) + +/* The reverse of the above */ +#define MPPE_CI_TO_OPTS(ci, opts) \ + do { \ + u_char *ptr =3D ci; /* u_char[4] */ \ + \ + opts =3D 0; \ + \ + /* H bit */ \ + if (!(ptr[0] & MPPE_H_BIT)) \ + opts |=3D MPPE_OPT_STATEFUL; \ + \ + /* S,L bits */ \ + if (ptr[3] & MPPE_S_BIT) \ + opts |=3D MPPE_OPT_128; \ + if (ptr[3] & MPPE_L_BIT) \ + opts |=3D MPPE_OPT_40; \ + \ + /* M,D,C bits */ \ + if (ptr[3] & MPPE_M_BIT) \ + opts |=3D MPPE_OPT_56; \ + if (ptr[3] & MPPE_D_BIT) \ + opts |=3D MPPE_OPT_D; \ + if (ptr[3] & MPPE_C_BIT) \ + opts |=3D MPPE_OPT_MPPC; \ + \ + /* Other bits */ \ + if (ptr[0] & ~MPPE_H_BIT) \ + opts |=3D MPPE_OPT_UNKNOWN; \ + if (ptr[1] || ptr[2]) \ + opts |=3D MPPE_OPT_UNKNOWN; \ + if (ptr[3] & ~MPPE_ALL_BITS) \ + opts |=3D MPPE_OPT_UNKNOWN; \ + } while (/* CONSTCOND */ 0) + +/* * Definitions for other, as yet unsupported, compression methods. */ =20 --NPukt5Otb9an/u20 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA0xR6Iavu95Lw/AkRAjOKAJkBJWyuu6vQLBzIaLNuprukHDOHIgCgiVv9 3l+eLzGgZl982DqgnqLz03A= =AWiM -----END PGP SIGNATURE----- --NPukt5Otb9an/u20-- From david@dgreaves.com Fri Jun 18 09:59:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 09:59:51 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IGxlgi025097 for ; Fri, 18 Jun 2004 09:59:48 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id B1BF1E6D34; Fri, 18 Jun 2004 17:59:15 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21114-03; Fri, 18 Jun 2004 17:59:15 +0100 (BST) Received: from oak.dgreaves.com (modem-2898.karuhiruhi.dialup.pol.co.uk [81.78.139.82]) by mail.ukfsn.org (Postfix) with ESMTP id 838DAE6A8C; Fri, 18 Jun 2004 17:59:13 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.86]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BbMkF-0004wU-Pu; Fri, 18 Jun 2004 18:01:39 +0100 Message-ID: <40D31F79.3000903@dgreaves.com> Date: Fri, 18 Jun 2004 17:59:37 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Venkatesan, Ganesh" Cc: Jens Laas , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: 2.6.6 e1000 ifconfig: page allocation failure References: <468F3FDA28AA87429AD807992E22D07E01767AF6@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01767AF6@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 8811 Lines: 285 On the 2.6.6 server machine: ifconfig eth0 mtu 9000 gives an oops in the usb? Unable to handle kernel paging request at virtual address 92a8292a printing eip: d1163305 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010286 (2.6.6) EIP is at usb_buffer_free+0x15/0x50 [usbcore] eax: cea2ec00 ebx: c13665e8 ecx: 00000001 edx: 92a8290a esi: c13665ec edi: cf0439dc ebp: cf58eef4 esp: c3535f44 ds: 007b es: 007b ss: 0068 Process usb (pid: 2744, threadinfo=c3534000 task=cf245370) Stack: cba80d00 c13665e8 c13665ec cf0439dc d106e3a6 cea2ec00 00002000 cf636000 0f636000 c13665e8 d106e4a9 c13665e8 cf122980 cffe0280 c01470d3 cf0439dc cf122980 cf122980 00000000 cf27f200 c3534000 c0145a19 cf122980 cf27f200 Call Trace: [] usblp_cleanup+0x46/0xb0 [usblp] [] usblp_release+0x59/0x60 [usblp] [] __fput+0xe3/0x100 [] filp_close+0x59/0x90 [] sys_close+0x50/0x60 [] syscall_call+0x7/0xb Code: 8b 4a 20 85 c9 74 07 8b 41 18 85 c0 75 04 83 c4 10 c3 8b 44 <6>usb 1-1: new full speed USB device using address 3 drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04B8 pid 0x0005 ifconfig: page allocation failure. order:3, mode:0x20 Call Trace: [] __alloc_pages+0x2af/0x2f0 [] __get_free_pages+0x25/0x40 [] cache_grow+0x87/0x230 [] cache_alloc_refill+0x139/0x200 [] __kmalloc+0x70/0x80 [] alloc_skb+0x49/0xe0 [] e1000_alloc_rx_buffers+0x62/0x100 [e1000] [] e1000_up+0x45/0xb0 [e1000] [] e1000_change_mtu+0x7c/0xd0 [e1000] [] dev_set_mtu+0x79/0x90 [] dev_ioctl+0x1e9/0x270 [] inet_ioctl+0x8e/0xa0 [] sock_ioctl+0xb5/0x250 [] sys_ioctl+0xad/0x210 [] do_page_fault+0x0/0x4ff [] syscall_call+0x7/0xb MemTotal: 256440 kB MemFree: 2576 kB Buffers: 18276 kB Cached: 202048 kB SwapCached: 0 kB Active: 112492 kB Inactive: 115324 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 256440 kB LowFree: 2576 kB SwapTotal: 522100 kB SwapFree: 522100 kB Dirty: 8 kB Writeback: 0 kB Mapped: 14856 kB Slab: 16920 kB Committed_AS: 20272 kB PageTables: 368 kB VmallocTotal: 770040 kB VmallocUsed: 10656 kB VmallocChunk: 759264 kB I have had similar on the stable box when it's been used for a while. I did: ifconfig eth1 mtu 9000 on the good machine and it gave me this: Jun 18 16:33:08 haze kernel: printk: 1 messages suppressed. Jun 18 16:33:08 haze kernel: ifconfig: page allocation failure. order:3, mode:0x20 Jun 18 16:33:08 haze kernel: [__alloc_pages+728/848] __alloc_pages+0x2d8/0x350 Jun 18 16:33:08 haze kernel: [__get_free_pages+37/64] __get_free_pages+0x25/0x40 Jun 18 16:33:08 haze kernel: [kmem_getpages+32/176] kmem_getpages+0x20/0xb0 Jun 18 16:33:08 haze kernel: [cache_grow+166/512] cache_grow+0xa6/0x200 Jun 18 16:33:08 haze kernel: [cache_alloc_refill+342/544] cache_alloc_refill+0x156/0x220 Jun 18 16:33:08 haze kernel: [__kmalloc+116/128] __kmalloc+0x74/0x80 Jun 18 16:33:08 haze kernel: [alloc_skb+71/224] alloc_skb+0x47/0xe0 Jun 18 16:33:08 haze kernel: [pg0+945227150/1069572096] e1000_alloc_rx_buffers+0x5e/0x100 [e1000] Jun 18 16:33:08 haze kernel: [pg0+945213509/1069572096] e1000_up+0x45/0xb0 [e1000] Jun 18 16:33:08 haze kernel: [pg0+945223248/1069572096] e1000_change_mtu+0x80/0x110 [e1000] Jun 18 16:33:08 haze kernel: [dev_set_mtu+121/144] dev_set_mtu+0x79/0x90 Jun 18 16:33:08 haze kernel: [dev_ioctl+501/640] dev_ioctl+0x1f5/0x280 Jun 18 16:33:08 haze kernel: [inet_ioctl+142/160] inet_ioctl+0x8e/0xa0 Jun 18 16:33:08 haze kernel: [sock_ioctl+233/656] sock_ioctl+0xe9/0x290 Jun 18 16:33:08 haze kernel: [sys_ioctl+239/608] sys_ioctl+0xef/0x260 Jun 18 16:33:08 haze kernel: [do_page_fault+0/1242] do_page_fault+0x0/0x4da Jun 18 16:33:08 haze kernel: [syscall_call+7/11] syscall_call+0x7/0xb it had root@haze:~ # cat /proc/meminfo MemTotal: 1036868 kB MemFree: 7564 kB Buffers: 30720 kB Cached: 756496 kB SwapCached: 0 kB Active: 553348 kB Inactive: 362700 kB HighTotal: 131056 kB HighFree: 252 kB LowTotal: 905812 kB LowFree: 7312 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB Mapped: 179532 kB Slab: 105264 kB Committed_AS: 298092 kB PageTables: 1504 kB VmallocTotal: 114680 kB VmallocUsed: 2112 kB VmallocChunk: 112376 kB I could repeat this by mtu 1500, mtu 9000. Somehow the distro hadn't mkswap'ed the swap so I added swap and the problem went away. if I swapoff then every time I set the mtu to 9000 I get the page allocation failure. I don't think this should happen but I'm not sure if I *must* have swap? Also I did this whilst the interface was up (it let me). David Venkatesan, Ganesh wrote: >Jens/David: > >Did not mean to get off the list. For some reason, my subscription to >netdev is not working (even after re-subscribing). So, I grabbed your >message off of the archive. > >I am trying to recreate your failure scenario in our lab. In the >meantime, please send me any new information you have on this issue. > >Thanks, >ganesh > >------------------------------------------------- >Ganesh Venkatesan >Network/Storage Division, Hillsboro, OR > >-----Original Message----- >From: David Greaves [mailto:david@dgreaves.com] >Sent: Friday, June 18, 2004 5:52 AM >To: Jens Laas >Cc: Stephen Hemminger; netdev@oss.sgi.com; Venkatesan, Ganesh >Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ >delay scheduler > >New info: >I booted into XP and the card works there - so it doesn't look like a >simple hardware incompatibility. >[I've got no real way to test the performance but cygwin's wget against >apache1.3 on the linux box returns about 25M/s initially and then 15M/s >sustained for 500Mb] > >Jens Laas wrote: > > > >>>I'm speaking with Ganesh Venkatesan at intel about it. Ganesh you >>>went off list - do you want to include Jens or maybe go back on-list? >>> >>> >>If others run into this problem I'm sure they'll appreciate if its on >>list. >>Since we have no idea what causes this (AFAIK) it may be a more >>general problem than the device driver. >> >> > >I tend to agree - but I wasn't sure if this was the place and I'll do as > >I'm told ;) > > > >>>A simple failure case for me is : 'ping -s 1500 ' >>>This doesn't cause the timout but doesn't succeed either. >>> >>>ping -f with standard packet size succeeds (slow rate though) and >>>doesn't timeout. >>> >>> >> >>I dont see the ping problems at all. Unless you try to ping when the >>interface has "hanged" ? >> >> > > thought that might be helpful. >Ping with -s and -f seems to allow me to trigger errors and it seems a >lot more debug-able than scp or nfs :) >No all tests are when it's reset and 'clean' > > > >>>============ >>>From hereon down it's 2.6.7 with Stephen's recent delay scheduler >>> >>> >patch > > >>>This changed the behaviour. >>> >>> >> >>This is strange unless you are actually using the delay scheduler ? >>Default is sch_generic (that is pfifo) that does not exhibit the >>problems correct by the patch. >> >> > >I'll go back and double check in case I cocked up... >(I noticed the e1000 module rebuild but you're right that's incidental) > >I've rebuilt the kernel and modules with and w/o patch and rebooted a >few times and I can't reproduce that effect - sorry for the red herring. >So after I reverted Stephens patch the results I reported are still >reproducable w/o the patch. > > > >>>10592 packets transmitted, 10591 packets received, 0% packet loss >>>round-trip min/avg/max = 5.4/5.5/83.5 ms >>> >>>Increasing Transmit Descriptors to 4096 avoids the No buffer space >>>available with packet sizes up to -s65468 (still 100% failure though) >>> >>> >>Increasing nr of buffers is not a way to fix the problem. >> >> > >agreed - however in my ignorance of the deep behaviour I'm reporting >things that affect behaviour in ways I don't expect. >I expected it to take longer to run out of buffers - that didn't happen >:) > >(Anyway, on retesting I find that this was wrong - I suspect the >interface was down and I didn't notice) > > > >>I had hoped to hear something about this from Scott.. >> >> > >I'm happy to hear from anyone - I don't have *that* long until my RMA >option expires and I don't fancy keeping them as ornaments! > >David > > > > > > From yoshfuji@linux-ipv6.org Fri Jun 18 10:17:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 10:17:28 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IHHMgi025917 for ; Fri, 18 Jun 2004 10:17:23 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1D54C33CE5; Sat, 19 Jun 2004 02:18:21 +0900 (JST) Date: Sat, 19 Jun 2004 02:18:18 +0900 (JST) Message-Id: <20040619.021818.04202102.yoshfuji@linux-ipv6.org> To: kalin@ThinRope.net Cc: andrew@walrond.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: Re: Iptables-1.2.9/10 compile failure with linux 2.6.7 headers From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <40D31EA6.5030207@ThinRope.net> References: <40D313DC.7000202@blue-labs.org> <200406181721.47968.andrew@walrond.org> <40D31EA6.5030207@ThinRope.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: 6126 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: 3701 Lines: 89 In article <40D31EA6.5030207@ThinRope.net> (at Sat, 19 Jun 2004 01:56:06 +0900), Kalin KOZHUHAROV says: > Yes, I confirm with linux-2.6.7 and iptables-1.2.9 I got: > gcc -march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -Iinclude -Wall -Wunused -I/usr/src/linux/include -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_stealth_sh.o -c extensions/libipt_stealth.c > distcc[6323] ERROR: compile on localhost failed > In file included from include/libiptc/libiptc.h:6, > from include/iptables.h:5, > from extensions/libipt_stealth.c:10: > /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:255: warning: no semicolon at end of struct or union > /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:255: error: syntax error before '*' token > /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:259: error: syntax error before '}' token > /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: type defaults to `int' in declaration of `DECLARE_MUTEX' > /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: parameter names (without types) in function declaration > /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: `DECLARE_MUTEX' declared `static' but never defined > make: *** [extensions/libipt_stealth_sh.o] Error 1 > > Last time I recompiled it with 2.6.6 it was ok. The compiled version still seems to work with 2.6.7 for now. Please try this. Thanks ===== include/linux/netfilter.h 1.9 vs edited ===== --- 1.9/include/linux/netfilter.h 2004-06-07 12:15:03 +09:00 +++ edited/include/linux/netfilter.h 2004-06-19 02:10:55 +09:00 @@ -10,6 +10,7 @@ #include #include #endif +#include /* Responses from hook functions. */ #define NF_DROP 0 ===== include/linux/netfilter_arp/arp_tables.h 1.3 vs edited ===== --- 1.3/include/linux/netfilter_arp/arp_tables.h 2004-06-04 09:52:00 +09:00 +++ edited/include/linux/netfilter_arp/arp_tables.h 2004-06-19 02:08:09 +09:00 @@ -16,7 +16,7 @@ #include #include #endif - +#include #include #define ARPT_FUNCTION_MAXNAMELEN 30 ===== include/linux/netfilter_ipv4/ip_tables.h 1.7 vs edited ===== --- 1.7/include/linux/netfilter_ipv4/ip_tables.h 2004-06-07 12:15:03 +09:00 +++ edited/include/linux/netfilter_ipv4/ip_tables.h 2004-06-19 02:08:39 +09:00 @@ -22,6 +22,7 @@ #include #include #endif +#include #include #define IPT_FUNCTION_MAXNAMELEN 30 @@ -336,8 +337,8 @@ /* * Main firewall chains definitions and global var's definitions. */ -static DECLARE_MUTEX(ipt_mutex); #ifdef __KERNEL__ +static DECLARE_MUTEX(ipt_mutex); #include extern void ipt_init(void) __init; ===== include/linux/netfilter_ipv6/ip6_tables.h 1.6 vs edited ===== --- 1.6/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-07 12:15:04 +09:00 +++ edited/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-19 02:09:29 +09:00 @@ -22,6 +22,7 @@ #include #include #endif +#include #include #define IP6T_FUNCTION_MAXNAMELEN 30 @@ -106,7 +107,9 @@ u_int64_t pcnt, bcnt; /* Packet and byte counters */ }; +#ifdef __KERNEL__ static DECLARE_MUTEX(ip6t_mutex); +#endif /* Values for "flag" field in struct ip6t_ip6 (general ip6 structure). */ #define IP6T_F_PROTO 0x01 /* Set if rule cares about upper -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From mdomsch@lists.us.dell.com Fri Jun 18 10:55:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 10:55:32 -0700 (PDT) Received: from lists.us.dell.com (linux.us.dell.com [143.166.224.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IHtQgi027617 for ; Fri, 18 Jun 2004 10:55:27 -0700 Received: from lists.us.dell.com (localhost.localdomain [127.0.0.1]) by lists.us.dell.com (8.12.10/8.12.10/Dell.IT.3.31.03) with ESMTP id i5IGAq8o020602; Fri, 18 Jun 2004 11:10:52 -0500 Received: (from mdomsch@localhost) by lists.us.dell.com (8.12.10/8.12.10/Submit) id i5IGAqDR020600; Fri, 18 Jun 2004 11:10:52 -0500 Date: Fri, 18 Jun 2004 11:10:52 -0500 From: Matt Domsch To: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net Subject: RFC: [1/3] PPP MPPE module Message-ID: <20040618161052.GF19269@lists.us.dell.com> References: <20040618161001.GE19269@lists.us.dell.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NGIwU0kFl1Z1A3An" Content-Disposition: inline In-Reply-To: <20040618161001.GE19269@lists.us.dell.com> User-Agent: Mutt/1.4.1i X-archive-position: 6127 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev Content-Length: 22141 Lines: 734 --NGIwU0kFl1Z1A3An Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 18, 2004 at 11:10:01AM -0500, Matt Domsch wrote: > 1) Add ppp_mppe.c file to drivers/net --=20 Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com --- /dev/null Thu Apr 11 09:25:15 2002 +++ linux-2.6-mppe/drivers/net/ppp_mppe.c Fri Jun 18 10:42:11 2004 @@ -0,0 +1,695 @@ +/* + * ppp_mppe_compress.c - interface MPPE to the PPP code. + * This version is for use with Linux kernel 2.2.19+, 2.4.18+ and 2.6.2+. + * + * By Frank Cusack . + * Copyright (c) 2002,2003,2004 Google, Inc. + * All rights reserved. + * + * License: + * Permission to use, copy, modify, and distribute this software and its + * documentation is hereby granted, provided that the above copyright + * notice appears in all copies. This software is provided without any + * warranty, express or implied. + * + * ALTERNATIVELY, provided that this notice is retained in full, this prod= uct + * may be distributed under the terms of the GNU General Public License (G= PL), + * in which case the provisions of the GPL apply INSTEAD OF those given ab= ove. + * + * 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 + * + * + * Changelog: + * 06/18/04 - Matt Domsch + * Use Linux kernel 2.6 arc4 and sha1 routines rather than + * providing our own. + * 2/15/04 - TS: added #include and testing for Kernel + * version before using=20 + * MOD_DEC_USAGE_COUNT/MOD_INC_USAGE_COUNT which are + * deprecated in 2.6 + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +static void +setup_sg(struct scatterlist *sg, const void *address, unsigned int length) +{ + sg[0].page =3D virt_to_page(address); + sg[0].offset =3D offset_in_page(address); + + if (sg[0].offset + length <=3D PAGE_SIZE) { + sg[0].length =3D length; + sg[1].page =3D 0; + sg[1].offset =3D 0; + sg[1].length =3D 0; + } else { + sg[0].length =3D PAGE_SIZE - sg[0].offset; + sg[1].length =3D length - sg[0].length; + sg[1].page =3D virt_to_page(address + sg[0].length); + sg[1].offset =3D offset_in_page(address + sg[0].length); /* 0 */ + } +} + +/* + * State for an MPPE (de)compressor. + */ +typedef struct ppp_mppe_state { + struct crypto_tfm *arc4; + struct crypto_tfm *sha1; + unsigned char *sha1_digest; + unsigned char master_key[MPPE_MAX_KEY_LEN]; + unsigned char session_key[MPPE_MAX_KEY_LEN]; + unsigned keylen; /* key length in bytes */ + /* NB: 128-bit =3D=3D 16, 40-bit =3D=3D 8! */ + /* If we want to support 56-bit, */ + /* the unit has to change to bits */ + unsigned char bits; /* MPPE control bits */ + unsigned ccount; /* 12-bit coherency count (seqno) */ + unsigned stateful; /* stateful mode flag */ + int discard; /* stateful mode packet loss flag */ + int sanity_errors; /* take down LCP if too many */ + int unit; + int debug; + struct compstat stats; +} ppp_mppe_state; + +/* ppp_mppe_state.bits definitions */ +#define MPPE_BIT_A 0x80 /* Encryption table were (re)inititalized */ +#define MPPE_BIT_B 0x40 /* MPPC only (not implemented) */ +#define MPPE_BIT_C 0x20 /* MPPC only (not implemented) */ +#define MPPE_BIT_D 0x10 /* This is an encrypted frame */ + +#define MPPE_BIT_FLUSHED MPPE_BIT_A +#define MPPE_BIT_ENCRYPTED MPPE_BIT_D + +#define MPPE_BITS(p) ((p)[4] & 0xf0) +#define MPPE_CCOUNT(p) ((((p)[4] & 0x0f) << 8) + (p)[5]) +#define MPPE_CCOUNT_SPACE 0x1000 /* The size of the ccount space */ + +#define MPPE_OVHD 2 /* MPPE overhead/packet */ +#define SANITY_MAX 1600 /* Max bogon factor we will tolerate */ + +#define SHA1_PAD_SIZE 40 +/* + * Key Derivation, from RFC 3078, RFC 3079. + * Equivalent to Get_Key() for MS-CHAP as described in RFC 3079. + */ +static void GetNewKeyFromSHA(ppp_mppe_state * state, unsigned char *Interi= mKey) +{ + static const unsigned char SHApad1[SHA1_PAD_SIZE] =3D + { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 + }; + static const unsigned char SHApad2[SHA1_PAD_SIZE] =3D + { 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2 + }; + struct scatterlist sg[2]; + + crypto_digest_init(state->sha1); + setup_sg(sg, state->master_key, state->keylen); + crypto_digest_update(state->sha1, sg, state->keylen); + setup_sg(sg, SHApad1, sizeof(SHApad1)); + crypto_digest_update(state->sha1, sg, sizeof(SHApad1)); + setup_sg(sg, state->session_key, state->keylen); + crypto_digest_update(state->sha1, sg, state->keylen); + setup_sg(sg, SHApad2, sizeof(SHApad2)); + crypto_digest_update(state->sha1, sg, sizeof(SHApad2)); + crypto_digest_final(state->sha1, state->sha1_digest); + memcpy(InterimKey, state->sha1_digest, state->keylen); +} + +/* + * Perform the MPPE rekey algorithm, from RFC 3078, sec. 7.3. + * Well, not what's written there, but rather what they meant. + */ +static void mppe_rekey(ppp_mppe_state * state, int initial_key) +{ + unsigned char InterimKey[MPPE_MAX_KEY_LEN]; + struct scatterlist sg_in[2], sg_out[2]; + + GetNewKeyFromSHA(state, InterimKey); + if (!initial_key) { + crypto_cipher_setkey(state->arc4, InterimKey, state->keylen); + setup_sg(sg_in, InterimKey, state->keylen); + setup_sg(sg_out, state->session_key, state->keylen); + crypto_cipher_encrypt(state->arc4, sg_out, sg_in, + state->keylen); + } else { + memcpy(state->session_key, InterimKey, state->keylen); + } + if (state->keylen =3D=3D 8) { + /* See RFC 3078 */ + state->session_key[0] =3D 0xd1; + state->session_key[1] =3D 0x26; + state->session_key[2] =3D 0x9e; + } + crypto_cipher_setkey(state->arc4, state->session_key, state->keylen); +} + +/* + * Allocate space for a (de)compressor. + */ +static void *mppe_alloc(unsigned char *options, int optlen) +{ + ppp_mppe_state *state; + unsigned int digestsize; + + if (optlen !=3D CILEN_MPPE + sizeof(state->master_key) + || options[0] !=3D CI_MPPE || options[1] !=3D CILEN_MPPE) + goto out; + + state =3D (ppp_mppe_state *) kmalloc(sizeof(*state), GFP_KERNEL); + if (state =3D=3D NULL) + goto out; + + memset(state, 0, sizeof(*state)); + + state->arc4 =3D crypto_alloc_tfm("arc4", 0); + if (!state->arc4) + goto out_free; + state->sha1 =3D crypto_alloc_tfm("sha1", 0); + if (!state->sha1) + goto out_arc4; + digestsize =3D crypto_tfm_alg_digestsize(state->sha1); + if (digestsize < MPPE_MAX_KEY_LEN) + goto out_sha1; + state->sha1_digest =3D kmalloc(digestsize, GFP_KERNEL); + if (!state->sha1_digest) + goto out_sha1; + + /* Save keys. */ + memcpy(state->master_key, &options[CILEN_MPPE], + sizeof(state->master_key)); + memcpy(state->session_key, state->master_key, + sizeof(state->master_key)); + /* + * We defer initial key generation until mppe_init(), as mppe_alloc() + * is called frequently during negotiation. + */ + + return (void *)state; + + out_sha1: + crypto_free_tfm(state->sha1); + out_arc4: + crypto_free_tfm(state->arc4); + out_free: + kfree(state); + out: + return NULL; +} + +/* + * Deallocate space for a (de)compressor. + */ +static void mppe_free(void *arg) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + + if (state) { + if (state->arc4) + crypto_free_tfm(state->arc4); + if (state->sha1) + crypto_free_tfm(state->sha1); + if (state->sha1_digest) + kfree(state->sha1_digest); + kfree(state); + } +} + +/*=20 + * Initialize (de)compressor state. + */ +static int +mppe_init(void *arg, unsigned char *options, int optlen, int unit, int deb= ug, + const char *debugstr) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + unsigned char mppe_opts; + + if (optlen !=3D CILEN_MPPE + || options[0] !=3D CI_MPPE || options[1] !=3D CILEN_MPPE) + return 0; + + MPPE_CI_TO_OPTS(&options[2], mppe_opts); + if (mppe_opts & MPPE_OPT_128) + state->keylen =3D 16; + else if (mppe_opts & MPPE_OPT_40) + state->keylen =3D 8; + else { + printk(KERN_WARNING "%s[%d]: unknown key length\n", debugstr, + unit); + return 0; + } + if (mppe_opts & MPPE_OPT_STATEFUL) + state->stateful =3D 1; + + /* Generate the initial session key. */ + mppe_rekey(state, 1); + + if (debug) { + int i; + char mkey[sizeof(state->master_key) * 2 + 1]; + char skey[sizeof(state->session_key) * 2 + 1]; + + printk(KERN_DEBUG "%s[%d]: initialized with %d-bit %s mode\n", + debugstr, unit, (state->keylen =3D=3D 16) ? 128 : 40, + (state->stateful) ? "stateful" : "stateless"); + + for (i =3D 0; i < sizeof(state->master_key); i++) + sprintf(mkey + i * 2, "%.2x", state->master_key[i]); + for (i =3D 0; i < sizeof(state->session_key); i++) + sprintf(skey + i * 2, "%.2x", state->session_key[i]); + printk(KERN_DEBUG + "%s[%d]: keys: master: %s initial session: %s\n", + debugstr, unit, mkey, skey); + } + + /* + * Initialize the coherency count. The initial value is not specified + * in RFC 3078, but we can make a reasonable assumption that it will + * start at 0. Setting it to the max here makes the comp/decomp code + * do the right thing (determined through experiment). + */ + state->ccount =3D MPPE_CCOUNT_SPACE - 1; + + /* + * Note that even though we have initialized the key table, we don't + * set the FLUSHED bit. This is contrary to RFC 3078, sec. 3.1. + */ + state->bits =3D MPPE_BIT_ENCRYPTED; + + state->unit =3D unit; + state->debug =3D debug; + + return 1; +} + +static int +mppe_comp_init(void *arg, unsigned char *options, int optlen, int unit, + int hdrlen, int debug) +{ + /* ARGSUSED */ + return mppe_init(arg, options, optlen, unit, debug, "mppe_comp_init"); +} + +/* + * We received a CCP Reset-Request (actually, we are sending a Reset-Ack), + * tell the compressor to rekey. Note that we MUST NOT rekey for + * every CCP Reset-Request; we only rekey on the next xmit packet. + * We might get multiple CCP Reset-Requests if our CCP Reset-Ack is lost. + * So, rekeying for every CCP Reset-Request is broken as the peer will not + * know how many times we've rekeyed. (If we rekey and THEN get another + * CCP Reset-Request, we must rekey again.) + */ +static void mppe_comp_reset(void *arg) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + + state->bits |=3D MPPE_BIT_FLUSHED; +} + +/* + * Compress (encrypt) a packet. + * It's strange to call this a compressor, since the output is always + * MPPE_OVHD + 2 bytes larger than the input. + */ +int +mppe_compress(void *arg, unsigned char *ibuf, unsigned char *obuf, + int isize, int osize) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + int proto; + struct scatterlist sg_in[2], sg_out[2]; + + /* + * Check that the protocol is in the range we handle. + */ + proto =3D PPP_PROTOCOL(ibuf); + if (proto < 0x0021 || proto > 0x00fa) + return 0; + + /* Make sure we have enough room to generate an encrypted packet. */ + if (osize < isize + MPPE_OVHD + 2) { + /* Drop the packet if we should encrypt it, but can't. */ + printk(KERN_DEBUG "mppe_compress[%d]: osize too small! " + "(have: %d need: %d)\n", state->unit, + osize, osize + MPPE_OVHD + 2); + return -1; + } + + osize =3D isize + MPPE_OVHD + 2; + + /* + * Copy over the PPP header and set control bits. + */ + obuf[0] =3D PPP_ADDRESS(ibuf); + obuf[1] =3D PPP_CONTROL(ibuf); + obuf[2] =3D PPP_COMP >> 8; /* isize + MPPE_OVHD + 1 */ + obuf[3] =3D PPP_COMP; /* isize + MPPE_OVHD + 2 */ + obuf +=3D PPP_HDRLEN; + + state->ccount =3D (state->ccount + 1) % MPPE_CCOUNT_SPACE; + if (state->debug >=3D 7) + printk(KERN_DEBUG "mppe_compress[%d]: ccount %d\n", state->unit, + state->ccount); + obuf[0] =3D state->ccount >> 8; + obuf[1] =3D state->ccount & 0xff; + + if (!state->stateful || /* stateless mode */ + ((state->ccount & 0xff) =3D=3D 0xff) || /* "flag" packet */ + (state->bits & MPPE_BIT_FLUSHED)) { /* CCP Reset-Request */ + /* We must rekey */ + if (state->debug && state->stateful) + printk(KERN_DEBUG "mppe_compress[%d]: rekeying\n", + state->unit); + mppe_rekey(state, 0); + state->bits |=3D MPPE_BIT_FLUSHED; + } + obuf[0] |=3D state->bits; + state->bits &=3D ~MPPE_BIT_FLUSHED; /* reset for next xmit */ + + obuf +=3D MPPE_OVHD; + ibuf +=3D 2; /* skip to proto field */ + isize -=3D 2; + + /* Encrypt packet */ + setup_sg(sg_in, ibuf, isize); + setup_sg(sg_out, obuf, osize); + crypto_cipher_encrypt(state->arc4, sg_out, sg_in, isize); + + state->stats.unc_bytes +=3D isize; + state->stats.unc_packets++; + state->stats.comp_bytes +=3D osize; + state->stats.comp_packets++; + + return osize; +} + +/* + * Since every frame grows by MPPE_OVHD + 2 bytes, this is always going + * to look bad ... and the longer the link is up the worse it will get. + */ +static void mppe_comp_stats(void *arg, struct compstat *stats) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + + *stats =3D state->stats; +} + +static int +mppe_decomp_init(void *arg, unsigned char *options, int optlen, int unit, + int hdrlen, int mru, int debug) +{ + /* ARGSUSED */ + return mppe_init(arg, options, optlen, unit, debug, "mppe_decomp_init"); +} + +/* + * We received a CCP Reset-Ack. Just ignore it. + */ +static void mppe_decomp_reset(void *arg) +{ + /* ARGSUSED */ + return; +} + +/* + * Decompress (decrypt) an MPPE packet. + */ +int +mppe_decompress(void *arg, unsigned char *ibuf, int isize, unsigned char *= obuf, + int osize) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + unsigned ccount; + int flushed =3D MPPE_BITS(ibuf) & MPPE_BIT_FLUSHED; + int sanity =3D 0; + struct scatterlist sg_in[2], sg_out[2]; + + if (isize <=3D PPP_HDRLEN + MPPE_OVHD) { + if (state->debug) + printk(KERN_DEBUG + "mppe_decompress[%d]: short pkt (%d)\n", + state->unit, isize); + return DECOMP_ERROR; + } + + /* + * Make sure we have enough room to decrypt the packet. + * Note that for our test we only subtract 1 byte whereas in + * mppe_compress() we added 2 bytes (+MPPE_OVHD); + * this is to account for possible PFC. + */ + if (osize < isize - MPPE_OVHD - 1) { + printk(KERN_DEBUG "mppe_decompress[%d]: osize too small! " + "(have: %d need: %d)\n", state->unit, + osize, isize - MPPE_OVHD - 1); + return DECOMP_ERROR; + } + osize =3D isize - MPPE_OVHD - 2; /* assume no PFC */ + + ccount =3D MPPE_CCOUNT(ibuf); + if (state->debug >=3D 7) + printk(KERN_DEBUG "mppe_decompress[%d]: ccount %d\n", + state->unit, ccount); + + /* sanity checks -- terminate with extreme prejudice */ + if (!(MPPE_BITS(ibuf) & MPPE_BIT_ENCRYPTED)) { + printk(KERN_DEBUG + "mppe_decompress[%d]: ENCRYPTED bit not set!\n", + state->unit); + state->sanity_errors +=3D 100; + sanity =3D 1; + } + if (!state->stateful && !flushed) { + printk(KERN_DEBUG "mppe_decompress[%d]: FLUSHED bit not set in " + "stateless mode!\n", state->unit); + state->sanity_errors +=3D 100; + sanity =3D 1; + } + if (state->stateful && ((ccount & 0xff) =3D=3D 0xff) && !flushed) { + printk(KERN_DEBUG "mppe_decompress[%d]: FLUSHED bit not set on " + "flag packet!\n", state->unit); + state->sanity_errors +=3D 100; + sanity =3D 1; + } + + if (sanity) { + if (state->sanity_errors < SANITY_MAX) + return DECOMP_ERROR; + else + /* + * Take LCP down if the peer is sending too many bogons. + * We don't want to do this for a single or just a few + * instances since it could just be due to packet corruption. + */ + return DECOMP_FATALERROR; + } + + /* + * Check the coherency count. + */ + + if (!state->stateful) { + /* RFC 3078, sec 8.1. Rekey for every packet. */ + while (state->ccount !=3D ccount) { + mppe_rekey(state, 0); + state->ccount =3D (state->ccount + 1) % MPPE_CCOUNT_SPACE; + } + } else { + /* RFC 3078, sec 8.2. */ + if (!state->discard) { + /* normal state */ + state->ccount =3D (state->ccount + 1) % MPPE_CCOUNT_SPACE; + if (ccount !=3D state->ccount) { + /* + * (ccount > state->ccount) + * Packet loss detected, enter the discard state. + * Signal the peer to rekey (by sending a CCP Reset-Request). + */ + state->discard =3D 1; + return DECOMP_ERROR; + } + } else { + /* discard state */ + if (!flushed) { + /* ccp.c will be silent (no additional CCP Reset-Requests). */ + return DECOMP_ERROR; + } else { + /* Rekey for every missed "flag" packet. */ + while ((ccount & ~0xff) !=3D + (state->ccount & ~0xff)) { + mppe_rekey(state, 0); + state->ccount =3D + (state->ccount + + 256) % MPPE_CCOUNT_SPACE; + } + + /* reset */ + state->discard =3D 0; + state->ccount =3D ccount; + /* + * Another problem with RFC 3078 here. It implies that the + * peer need not send a Reset-Ack packet. But RFC 1962 + * requires it. Hopefully, M$ does send a Reset-Ack; even + * though it isn't required for MPPE synchronization, it is + * required to reset CCP state. + */ + } + } + if (flushed) + mppe_rekey(state, 0); + } + + /* + * Fill in the first part of the PPP header. The protocol field + * comes from the decrypted data. + */ + obuf[0] =3D PPP_ADDRESS(ibuf); /* +1 */ + obuf[1] =3D PPP_CONTROL(ibuf); /* +1 */ + obuf +=3D 2; + ibuf +=3D PPP_HDRLEN + MPPE_OVHD; + isize -=3D PPP_HDRLEN + MPPE_OVHD; /* -6 */ + /* net osize: isize-4 */ + + /* + * Decrypt the first byte in order to check if it is + * a compressed or uncompressed protocol field. + */ + setup_sg(sg_in, ibuf, 1); + setup_sg(sg_out, obuf, 1); + crypto_cipher_decrypt(state->arc4, sg_out, sg_in, 1); + + /* + * Do PFC decompression. + * This would be nicer if we were given the actual sk_buff + * instead of a char *. + */ + if ((obuf[0] & 0x01) !=3D 0) { + obuf[1] =3D obuf[0]; + obuf[0] =3D 0; + obuf++; + osize++; + } + + /* And finally, decrypt the rest of the packet. */ + setup_sg(sg_in, ibuf + 1, isize - 1); + setup_sg(sg_out, obuf + 1, osize - 1); + crypto_cipher_decrypt(state->arc4, sg_out, sg_in, isize - 1); + + state->stats.unc_bytes +=3D osize; + state->stats.unc_packets++; + state->stats.comp_bytes +=3D isize; + state->stats.comp_packets++; + + /* good packet credit */ + state->sanity_errors >>=3D 1; + + return osize; +} + +/* + * Incompressible data has arrived (this should never happen!). + * We should probably drop the link if the protocol is in the range + * of what should be encrypted. At the least, we should drop this + * packet. (How to do this?) + */ +static void mppe_incomp(void *arg, unsigned char *ibuf, int icnt) +{ + ppp_mppe_state *state =3D (ppp_mppe_state *) arg; + + if (state->debug && + (PPP_PROTOCOL(ibuf) >=3D 0x0021 && PPP_PROTOCOL(ibuf) <=3D 0x00fa)) + printk(KERN_DEBUG + "mppe_incomp[%d]: incompressible (unencrypted) data! " + "(proto %04x)\n", state->unit, PPP_PROTOCOL(ibuf)); + + state->stats.inc_bytes +=3D icnt; + state->stats.inc_packets++; + state->stats.unc_bytes +=3D icnt; + state->stats.unc_packets++; +} + +/************************************************************* + * Module interface table + *************************************************************/ + +/* + * Procedures exported to if_ppp.c. + */ +struct compressor ppp_mppe =3D { + CI_MPPE, /* compress_proto */ + mppe_alloc, /* comp_alloc */ + mppe_free, /* comp_free */ + mppe_comp_init, /* comp_init */ + mppe_comp_reset, /* comp_reset */ + mppe_compress, /* compress */ + mppe_comp_stats, /* comp_stat */ + mppe_alloc, /* decomp_alloc */ + mppe_free, /* decomp_free */ + mppe_decomp_init, /* decomp_init */ + mppe_decomp_reset, /* decomp_reset */ + mppe_decompress, /* decompress */ + mppe_incomp, /* incomp */ + mppe_comp_stats, /* decomp_stat */ +}; + +/* + * ppp_mppe_init() + * + * Prior to allowing load, try to load the arc4 and sha1 crypto + * libraries. The actual use will be allocated later, but + * this way the module will fail to insmod if they aren't available. + */ + +int __init ppp_mppe_init(void) +{ + if (!(crypto_alg_available("arc4", 0) && + crypto_alg_available("sha1", 0))) + return -ENODEV; + + int answer =3D ppp_register_compressor(&ppp_mppe); + + if (answer =3D=3D 0) + printk(KERN_INFO "PPP MPPE Compression module registered\n"); + return answer; +} + +void __exit ppp_mppe_cleanup(void) +{ + ppp_unregister_compressor(&ppp_mppe); +} + +module_init(ppp_mppe_init); +module_exit(ppp_mppe_cleanup); +MODULE_LICENSE("Dual BSD/GPL"); --NGIwU0kFl1Z1A3An Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA0xQMIavu95Lw/AkRApzJAJ9tGLqCIY1ZUGU09OVlWdCVi/trxQCfe/y5 pW0liK7Ato42siXYqxVwn7o= =U9j0 -----END PGP SIGNATURE----- --NGIwU0kFl1Z1A3An-- From shemminger@osdl.org Fri Jun 18 11:04:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 11:04:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5II41gi028457 for ; Fri, 18 Jun 2004 11:04: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 i5II3or21452; Fri, 18 Jun 2004 11:03:50 -0700 Date: Fri, 18 Jun 2004 11:03:50 -0700 From: Stephen Hemminger To: Matt Domsch Cc: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net Subject: Re: RFC: [1/3] PPP MPPE module Message-Id: <20040618110350.3983354f@dell_ss3.pdx.osdl.net> In-Reply-To: <20040618161052.GF19269@lists.us.dell.com> References: <20040618161001.GE19269@lists.us.dell.com> <20040618161052.GF19269@lists.us.dell.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: 6129 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: 3193 Lines: 103 Minor stuff. > +/* > + * State for an MPPE (de)compressor. > + */ > +typedef struct ppp_mppe_state { > + struct crypto_tfm *arc4; > + struct crypto_tfm *sha1; > + unsigned char *sha1_digest; > + unsigned char master_key[MPPE_MAX_KEY_LEN]; > + unsigned char session_key[MPPE_MAX_KEY_LEN]; > + unsigned keylen; /* key length in bytes */ > + /* NB: 128-bit == 16, 40-bit == 8! */ > + /* If we want to support 56-bit, */ > + /* the unit has to change to bits */ > + unsigned char bits; /* MPPE control bits */ > + unsigned ccount; /* 12-bit coherency count (seqno) */ > + unsigned stateful; /* stateful mode flag */ > + int discard; /* stateful mode packet loss flag */ > + int sanity_errors; /* take down LCP if too many */ > + int unit; > + int debug; > + struct compstat stats; > +} ppp_mppe_state; Is the typedef really making things clearer? no. > +/* ppp_mppe_state.bits definitions */ > +#define MPPE_BIT_A 0x80 /* Encryption table were (re)inititalized */ > +#define MPPE_BIT_B 0x40 /* MPPC only (not implemented) */ > +#define MPPE_BIT_C 0x20 /* MPPC only (not implemented) */ > +#define MPPE_BIT_D 0x10 /* This is an encrypted frame */ > + > +#define MPPE_BIT_FLUSHED MPPE_BIT_A > +#define MPPE_BIT_ENCRYPTED MPPE_BIT_D > + > +#define MPPE_BITS(p) ((p)[4] & 0xf0) > +#define MPPE_CCOUNT(p) ((((p)[4] & 0x0f) << 8) + (p)[5]) > +#define MPPE_CCOUNT_SPACE 0x1000 /* The size of the ccount space */ > + > +#define MPPE_OVHD 2 /* MPPE overhead/packet */ > +#define SANITY_MAX 1600 /* Max bogon factor we will tolerate */ > + > +#define SHA1_PAD_SIZE 40 > +/* > + * Key Derivation, from RFC 3078, RFC 3079. > + * Equivalent to Get_Key() for MS-CHAP as described in RFC 3079. > + */ > +static void GetNewKeyFromSHA(ppp_mppe_state * state, unsigned char *InterimKey) annoying RandomCaptialization > > +/* > + * Compress (encrypt) a packet. > + * It's strange to call this a compressor, since the output is always > + * MPPE_OVHD + 2 bytes larger than the input. > + */ > +int > +mppe_compress(void *arg, unsigned char *ibuf, unsigned char *obuf, > + int isize, int osize) > +{ This can be static since only call should be through table. > + > +/* > + * Decompress (decrypt) an MPPE packet. > + */ > +int > +mppe_decompress(void *arg, unsigned char *ibuf, int isize, unsigned char *obuf, > + int osize) > +{ Also can be static. > + > +/************************************************************* > + * Module interface table > + *************************************************************/ > + > +/* > + * Procedures exported to if_ppp.c. > + */ > +struct compressor ppp_mppe = { > + CI_MPPE, /* compress_proto */ > + mppe_alloc, /* comp_alloc */ > + mppe_free, /* comp_free */ > + mppe_comp_init, /* comp_init */ > + mppe_comp_reset, /* comp_reset */ > + mppe_compress, /* compress */ > + mppe_comp_stats, /* comp_stat */ > + mppe_alloc, /* decomp_alloc */ > + mppe_free, /* decomp_free */ > + mppe_decomp_init, /* decomp_init */ > + mppe_decomp_reset, /* decomp_reset */ > + mppe_decompress, /* decompress */ > + mppe_incomp, /* incomp */ > + mppe_comp_stats, /* decomp_stat */ > +}; Table can be static since it is hooked in with register call. From shemminger@osdl.org Fri Jun 18 11:11:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 11:11:38 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IIBZgi029077 for ; Fri, 18 Jun 2004 11:11:35 -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 i5IIBOr22804; Fri, 18 Jun 2004 11:11:24 -0700 Date: Fri, 18 Jun 2004 11:11:24 -0700 From: Stephen Hemminger To: Jens Laas Cc: David Greaves , netdev@oss.sgi.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out Message-Id: <20040618111124.3a2681b5@dell_ss3.pdx.osdl.net> In-Reply-To: References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.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: 6130 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: 2403 Lines: 66 To get to the root of these problems, could you: * Give full lspci -v output for the boards in question. * Are you using any special queuing or shaping (output of "tc qdisc ls") * You could try the following, which dumps out the state of the transmit ring in case of error. and tries to see if it is one of the other watchdog hooks in this driver. ------ diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2004-06-18 11:09:36 -07:00 +++ b/drivers/net/e1000/e1000_main.c 2004-06-18 11:09:36 -07:00 @@ -1426,6 +1426,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: link lost but ring is full\n", netdev->name); schedule_work(&adapter->tx_timeout_task); } } @@ -1450,8 +1451,12 @@ i = txdr->next_to_clean; if(txdr->buffer_info[i].dma && time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) { + printk("%s: may be hung last tx was %ld ticks\n", + netdev->name, + (long)(jiffies - txdr->buffer_info[i].time_stamp)); netif_stop_queue(netdev); + } /* Reset the timer */ mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ); @@ -1826,6 +1831,7 @@ { struct e1000_adapter *adapter = netdev->priv; + printk("%s: transmit timeout from queuing\n", netdev->name); /* Do the reset outside of interrupt context */ schedule_work(&adapter->tx_timeout_task); } @@ -1834,6 +1840,21 @@ e1000_tx_timeout_task(struct net_device *netdev) { struct e1000_adapter *adapter = netdev->priv; + unsigned long now = jiffies; + int i; + + printk("%s: state=0x%lx transmit ring size=%u count=%u to_use=%u to_clean=%u\n", + netdev->name, netdev->state, + adapter->tx_ring.size, adapter->tx_ring.count, + adapter->tx_ring.next_to_use, adapter->tx_ring.next_to_clean); + + for (i = 0; i < adapter->tx_ring.count; ++i) { + struct e1000_buffer *b = &adapter->tx_ring.buffer_info[i]; + printk(" %d: skb=%p dma=%llu length=%lu time=+%ld watch=%u\n", + i, b->skb, b->dma, b->length, + (long) (now - b->time_stamp), b->next_to_watch); + } + netif_device_detach(netdev); e1000_down(adapter); From kalin@ThinRope.net Fri Jun 18 11:36:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 11:36:30 -0700 (PDT) Received: from mail.tar.bz (j110113.ppp.asahi-net.or.jp [61.213.110.113]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IIaNgi030291 for ; Fri, 18 Jun 2004 11:36:23 -0700 Received: (qmail 31144 invoked by uid 89); 18 Jun 2004 18:36:16 -0000 Received: from sata.tar.bz (HELO ThinRope.net) (kalin.smtp@tar.bz@192.168.1.20) by gw1.tar.bz with SMTP; 18 Jun 2004 18:36:16 -0000 Message-ID: <40D3361B.5020304@ThinRope.net> Date: Sat, 19 Jun 2004 03:36:11 +0900 From: Kalin KOZHUHAROV User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040121 X-Accept-Language: bg, en, ja, ru, de MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org CC: andrew@walrond.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: Iptables-1.2.9/10 compile failure with linux 2.6.7 headers References: <40D313DC.7000202@blue-labs.org> <200406181721.47968.andrew@walrond.org> <40D31EA6.5030207@ThinRope.net> <20040619.021818.04202102.yoshfuji@linux-ipv6.org> In-Reply-To: <20040619.021818.04202102.yoshfuji@linux-ipv6.org> X-Enigmail-Version: 0.83.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: 6132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kalin@ThinRope.net Precedence: bulk X-list: netdev Content-Length: 4779 Lines: 116 YOSHIFUJI Hideaki wrote: > In article <40D31EA6.5030207@ThinRope.net> (at Sat, 19 Jun 2004 01:56:06 +0900), Kalin KOZHUHAROV says: > > >>Yes, I confirm with linux-2.6.7 and iptables-1.2.9 I got: >>gcc -march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -Iinclude -Wall -Wunused -I/usr/src/linux/include -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_stealth_sh.o -c extensions/libipt_stealth.c >>distcc[6323] ERROR: compile on localhost failed >>In file included from include/libiptc/libiptc.h:6, >> from include/iptables.h:5, >> from extensions/libipt_stealth.c:10: >>/usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:255: warning: no semicolon at end of struct or union >>/usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:255: error: syntax error before '*' token >>/usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:259: error: syntax error before '}' token >>/usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: type defaults to `int' in declaration of `DECLARE_MUTEX' >>/usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: parameter names (without types) in function declaration >>/usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: `DECLARE_MUTEX' declared `static' but never defined >>make: *** [extensions/libipt_stealth_sh.o] Error 1 >> >>Last time I recompiled it with 2.6.6 it was ok. The compiled version still seems to work with 2.6.7 for now. > > > Please try this. Thanks > > ===== include/linux/netfilter.h 1.9 vs edited ===== > --- 1.9/include/linux/netfilter.h 2004-06-07 12:15:03 +09:00 > +++ edited/include/linux/netfilter.h 2004-06-19 02:10:55 +09:00 > @@ -10,6 +10,7 @@ > #include > #include > #endif > +#include > > /* Responses from hook functions. */ > #define NF_DROP 0 > ===== include/linux/netfilter_arp/arp_tables.h 1.3 vs edited ===== > --- 1.3/include/linux/netfilter_arp/arp_tables.h 2004-06-04 09:52:00 +09:00 > +++ edited/include/linux/netfilter_arp/arp_tables.h 2004-06-19 02:08:09 +09:00 > @@ -16,7 +16,7 @@ > #include > #include > #endif > - > +#include > #include > > #define ARPT_FUNCTION_MAXNAMELEN 30 > ===== include/linux/netfilter_ipv4/ip_tables.h 1.7 vs edited ===== > --- 1.7/include/linux/netfilter_ipv4/ip_tables.h 2004-06-07 12:15:03 +09:00 > +++ edited/include/linux/netfilter_ipv4/ip_tables.h 2004-06-19 02:08:39 +09:00 > @@ -22,6 +22,7 @@ > #include > #include > #endif > +#include > #include > > #define IPT_FUNCTION_MAXNAMELEN 30 > @@ -336,8 +337,8 @@ > /* > * Main firewall chains definitions and global var's definitions. > */ > -static DECLARE_MUTEX(ipt_mutex); > #ifdef __KERNEL__ > +static DECLARE_MUTEX(ipt_mutex); > > #include > extern void ipt_init(void) __init; > ===== include/linux/netfilter_ipv6/ip6_tables.h 1.6 vs edited ===== > --- 1.6/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-07 12:15:04 +09:00 > +++ edited/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-19 02:09:29 +09:00 > @@ -22,6 +22,7 @@ > #include > #include > #endif > +#include > #include > > #define IP6T_FUNCTION_MAXNAMELEN 30 > @@ -106,7 +107,9 @@ > u_int64_t pcnt, bcnt; /* Packet and byte counters */ > }; > > +#ifdef __KERNEL__ > static DECLARE_MUTEX(ip6t_mutex); > +#endif > > /* Values for "flag" field in struct ip6t_ip6 (general ip6 structure). */ > #define IP6T_F_PROTO 0x01 /* Set if rule cares about upper > As far as I understand from this patch, this should be applied to the system headers... I thought `diff -Nru A B` was the format of choice in LKML... Anyway, thank you for the patch, but I am not thinking to patch linux-headers, as I like to refer to them as something more or less stable (As opposed to the current kernel). And just out of curiosity, I did: include $ patch --dry-run -p2 WWW: http://ThinRope.net/ From david@dgreaves.com Fri Jun 18 11:44:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 11:44:25 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IIiMgi030776 for ; Fri, 18 Jun 2004 11:44:23 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id B2A8AE6A86; Fri, 18 Jun 2004 19:43:47 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25567-12; Fri, 18 Jun 2004 19:43:47 +0100 (BST) Received: from oak.dgreaves.com (modem-252.putangitangi.dialup.pol.co.uk [81.78.192.252]) by mail.ukfsn.org (Postfix) with ESMTP id 23126E6A9F; Fri, 18 Jun 2004 19:43:45 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.86]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BbONQ-00056v-2a; Fri, 18 Jun 2004 19:46:12 +0100 Message-ID: <40D337FA.1080404@dgreaves.com> Date: Fri, 18 Jun 2004 19:44:10 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: Jens Laas , netdev@oss.sgi.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> <20040618111124.3a2681b5@dell_ss3.pdx.osdl.net> In-Reply-To: <20040618111124.3a2681b5@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 10305 Lines: 299 Stephen Hemminger wrote: >To get to the root of these problems, could you: > >* Give full lspci -v output for the boards in question. > > ash: 00:07.0 Ethernet controller: Intel Corp.: Unknown device 1076 Subsystem: Intel Corp.: Unknown device 1176 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 11 Memory at e3020000 (32-bit, non-prefetchable) [size=128K] Memory at e3000000 (32-bit, non-prefetchable) [size=128K] I/O ports at b400 [size=64] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- >* Are you using any special queuing or shaping (output of "tc qdisc ls") > > no root@ash:~ # tc qdisc ls RTNETLINK answers: Invalid argument Dump terminated >* You could try the following, which dumps out the state of the transmit ring > in case of error. and tries to see if it is one of the other watchdog hooks in > this driver. > > patched :) Test root@ash:/usr/src/linux # ifdown eth0 ; modprobe -r e1000;modprobe e1000; ifup eth0ifdown: interface eth0 not configured root@ash:/usr/src/linux # ping 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes 64 bytes from 10.0.1.1: icmp_seq=0 ttl=64 time=0.3 ms 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=0.1 ms 64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=0.1 ms 64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0.2 ms --- 10.0.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.3 ms root@ash:/usr/src/linux # ping -s 1500 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 1500 data bytes 1508 bytes from 10.0.1.1: icmp_seq=0 ttl=64 time=0.3 ms 1508 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=0.4 ms 1508 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=0.3 ms --- 10.0.1.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.4 ms root@ash:/usr/src/linux # ping -s 3000 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 3000 data bytes 3008 bytes from 10.0.1.1: icmp_seq=0 ttl=64 time=0.4 ms 3008 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0.3 ms --- 10.0.1.1 ping statistics --- 7 packets transmitted, 2 packets received, 71% packet loss round-trip min/avg/max = 0.3/0.3/0.4 ms messages: (the 'after 5000 jiffies' is mine) Jun 18 19:37:43 ash kernel: Copyright (c) 1999-2004 Intel Corporation. Jun 18 19:37:44 ash kernel: e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Co nnection Jun 18 19:37:46 ash kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex Jun 18 19:38:18 ash kernel: eth0: may be hung last tx was 2457 ticks Jun 18 19:38:20 ash kernel: eth0: may be hung last tx was 4457 ticks Jun 18 19:38:22 ash kernel: eth0: may be hung last tx was 6457 ticks Jun 18 19:38:24 ash kernel: eth0: may be hung last tx was 8457 ticks Jun 18 19:38:26 ash kernel: NETDEV WATCHDOG: eth0: transmit timed out after 5000 j iffies Jun 18 19:38:26 ash kernel: eth0: transmit timeout from queuing Jun 18 19:38:26 ash kernel: eth0: may be hung last tx was 10457 ticks Jun 18 19:38:26 ash kernel: eth0: state=0x7 transmit ring size=4096 count=256 to_u se=66 to_clean=59 Jun 18 19:38:26 ash kernel: 0: skb=00000000 dma=0 length=42 time=+29527 watch=0 Jun 18 19:38:26 ash kernel: 1: skb=00000000 dma=0 length=98 time=+29527 watch=1 Jun 18 19:38:26 ash kernel: 2: skb=00000000 dma=0 length=98 time=+28526 watch=2 Jun 18 19:38:26 ash kernel: 3: skb=00000000 dma=0 length=98 time=+27525 watch=3 Jun 18 19:38:26 ash kernel: 4: skb=00000000 dma=0 length=98 time=+26524 watch=4 Jun 18 19:38:26 ash kernel: 5: skb=00000000 dma=0 length=42 time=+24528 watch=5 Jun 18 19:38:26 ash kernel: 6: skb=00000000 dma=0 length=0 time=+20324251 watch=7 Jun 18 19:38:26 ash kernel: 7: skb=00000000 dma=0 length=110 time=+24510 watch=0 Jun 18 19:38:26 ash kernel: 8: skb=00000000 dma=0 length=0 time=+20324251 watch=9 Jun 18 19:38:26 ash kernel: 9: skb=00000000 dma=0 length=110 time=+24510 watch=0 Jun 18 19:38:26 ash kernel: 10: skb=00000000 dma=0 length=0 time=+20324251 watch= 11 Jun 18 19:38:26 ash kernel: 11: skb=00000000 dma=0 length=110 time=+24510 watch=0 Jun 18 19:38:26 ash kernel: 12: skb=00000000 dma=0 length=0 time=+20324251 watch= 13 Jun 18 19:38:26 ash kernel: 13: skb=00000000 dma=0 length=110 time=+24510 watch=0 Jun 18 19:38:26 ash kernel: 14: skb=00000000 dma=0 length=0 time=+20324251 watch= 15 Jun 18 19:38:26 ash kernel: 15: skb=00000000 dma=0 length=110 time=+24510 watch=0 Jun 18 19:38:26 ash kernel: 16: skb=00000000 dma=0 length=0 time=+20324251 watch= 17 Jun 18 19:38:26 ash kernel: 17: skb=00000000 dma=0 length=257 time=+24510 watch=0 Jun 18 19:38:26 ash kernel: 18: skb=00000000 dma=0 length=0 time=+20324251 watch= 19 Jun 18 19:38:26 ash kernel: 19: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 20: skb=00000000 dma=0 length=0 time=+20324251 watch= 21 Jun 18 19:38:26 ash kernel: 21: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 22: skb=00000000 dma=0 length=0 time=+20324251 watch= 23 Jun 18 19:38:26 ash kernel: 23: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 24: skb=00000000 dma=0 length=0 time=+20324251 watch= 25 Jun 18 19:38:26 ash kernel: 25: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 26: skb=00000000 dma=0 length=0 time=+20324251 watch= 27 Jun 18 19:38:26 ash kernel: 27: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 28: skb=00000000 dma=0 length=0 time=+20324251 watch= 29 Jun 18 19:38:26 ash kernel: 29: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 30: skb=00000000 dma=0 length=0 time=+20324251 watch= 31 Jun 18 19:38:26 ash kernel: 31: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 32: skb=00000000 dma=0 length=0 time=+20324251 watch= 33 Jun 18 19:38:26 ash kernel: 33: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 34: skb=00000000 dma=0 length=0 time=+20324251 watch= 35 Jun 18 19:38:26 ash kernel: 35: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 36: skb=00000000 dma=0 length=0 time=+20324251 watch= 37 Jun 18 19:38:26 ash kernel: 37: skb=00000000 dma=0 length=110 time=+22510 watch=0 Jun 18 19:38:26 ash kernel: 38: skb=00000000 dma=0 length=1514 time=+21082 watch= 38 Jun 18 19:38:26 ash kernel: 39: skb=00000000 dma=0 length=62 time=+21082 watch=39 Jun 18 19:38:26 ash kernel: 40: skb=00000000 dma=0 length=0 time=+20324251 watch= 41 Jun 18 19:38:26 ash kernel: 41: skb=00000000 dma=0 length=110 time=+20510 watch=0 Jun 18 19:38:26 ash kernel: 42: skb=00000000 dma=0 length=0 time=+20324251 watch= 43 Jun 18 19:38:26 ash kernel: 43: skb=00000000 dma=0 length=110 time=+20510 watch=0 Jun 18 19:38:26 ash kernel: 44: skb=00000000 dma=0 length=0 time=+20324251 watch= 45 Jun 18 19:38:26 ash kernel: 45: skb=00000000 dma=0 length=110 time=+20510 watch=0 Jun 18 19:38:26 ash kernel: 46: skb=00000000 dma=0 length=0 time=+20324251 watch= 47 Jun 18 19:38:26 ash kernel: 47: skb=00000000 dma=0 length=110 time=+20510 watch=0 Jun 18 19:38:26 ash kernel: 48: skb=00000000 dma=0 length=0 time=+20324251 watch= 49 Jun 18 19:38:26 ash kernel: 49: skb=00000000 dma=0 length=110 time=+20510 watch=0 Jun 18 19:38:26 ash kernel: 50: skb=00000000 dma=0 length=1514 time=+20081 watch= 50 Jun 18 19:38:26 ash kernel: 51: skb=00000000 dma=0 length=62 time=+20081 watch=51 Jun 18 19:38:26 ash kernel: 52: skb=00000000 dma=0 length=1514 time=+19080 watch= 52 Jun 18 19:38:26 ash kernel: 53: skb=00000000 dma=0 length=62 time=+19080 watch=53 Jun 18 19:38:26 ash kernel: 54: skb=00000000 dma=0 length=1514 time=+11459 watch= 54 Jun 18 19:38:26 ash kernel: 55: skb=00000000 dma=0 length=1514 time=+11458 watch= 55 Jun 18 19:38:26 ash kernel: 56: skb=00000000 dma=0 length=82 time=+11458 watch=56 Jun 18 19:38:26 ash kernel: 57: skb=00000000 dma=0 length=1514 time=+10457 watch= 57 Jun 18 19:38:26 ash kernel: 58: skb=00000000 dma=0 length=1514 time=+10457 watch= 58 Jun 18 19:38:26 ash kernel: 59: skb=f0740420 dma=934467074 length=82 time=+10457 watch=59 Jun 18 19:38:26 ash kernel: 60: skb=d6e91420 dma=397015042 length=1514 time=+9456 watch=60 Jun 18 19:38:26 ash kernel: 61: skb=f07406a0 dma=935571458 length=1514 time=+9456 watch=61 Jun 18 19:38:26 ash kernel: 62: skb=f3fcde20 dma=26358274 length=82 time=+9456 wa tch=62 Jun 18 19:38:26 ash kernel: 63: skb=f0740ba0 dma=397012994 length=1514 time=+8455 watch=63 Jun 18 19:38:26 ash kernel: 64: skb=d6e914c0 dma=935573506 length=1514 time=+8455 watch=64 Jun 18 19:38:26 ash kernel: 65: skb=f0740600 dma=937204738 length=82 time=+8455 w atch=65 Jun 18 19:38:26 ash kernel: 66: skb=00000000 dma=0 length=0 time=+20324251 watch= 0 Jun 18 19:38:26 ash kernel: eth0: link lost but ring is full Jun 18 19:38:26 ash kernel: eth0: state=0x16 transmit ring size=4096 count=256 to_ use=9 to_clean=2 Jun 18 19:38:26 ash kernel: 0: skb=00000000 dma=0 length=1514 time=+1 watch=0 Jun 18 19:38:26 ash kernel: 1: skb=00000000 dma=0 length=1514 time=+1 watch=1 Jun 18 19:38:26 ash kernel: 2: skb=f0740060 dma=26400258 length=82 time=+1 watch= 2 Jun 18 19:38:26 ash kernel: 3: skb=f0740ec0 dma=594843650 length=1514 time=+1 wat ch=3 Jun 18 19:38:26 ash kernel: 4: skb=d6e91a60 dma=594841602 length=1514 time=+1 wat ch=4 Jun 18 19:38:26 ash kernel: 5: skb=f0740560 dma=937203714 length=82 time=+1 watch =5 Jun 18 19:38:26 ash kernel: 6: skb=d6e919c0 dma=426745858 length=1514 time=+1 wat ch=6 Jun 18 19:38:26 ash kernel: 7: skb=d6e91880 dma=426747906 length=1514 time=+1 wat ch=7 Jun 18 19:38:26 ash kernel: 8: skb=f65ca920 dma=934469122 length=82 time=+1 watch =8 Jun 18 19:38:26 ash kernel: 9: skb=00000000 dma=0 length=0 time=+20324352 watch=0 Jun 18 19:38:26 ash kernel: 10: skb=00000000 dma=0 length=0 time=+20324352 watch= 0 =0 Jun 18 19:38:26 ash kernel: 255: skb=00000000 dma=0 length=0 time=+20324352 watch David From mdomsch@lists.us.dell.com Fri Jun 18 12:32:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 12:32:22 -0700 (PDT) Received: from lists.us.dell.com (lists.us.dell.com [143.166.224.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IJWJgi003148 for ; Fri, 18 Jun 2004 12:32:20 -0700 Received: from lists.us.dell.com (localhost.localdomain [127.0.0.1]) by lists.us.dell.com (8.12.10/8.12.10/Dell.IT.3.31.03) with ESMTP id i5IJVs8o025482; Fri, 18 Jun 2004 14:31:54 -0500 Received: (from mdomsch@localhost) by lists.us.dell.com (8.12.10/8.12.10/Submit) id i5IJVswr025480; Fri, 18 Jun 2004 14:31:54 -0500 Date: Fri, 18 Jun 2004 14:31:54 -0500 From: Matt Domsch To: Stephen Hemminger Cc: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net Subject: Re: [pptp-devel] Re: RFC: [1/3] PPP MPPE module Message-ID: <20040618193154.GH19269@lists.us.dell.com> References: <20040618161001.GE19269@lists.us.dell.com> <20040618161052.GF19269@lists.us.dell.com> <20040618110350.3983354f@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNpeiK4tTqhYOExY" Content-Disposition: inline In-Reply-To: <20040618110350.3983354f@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-archive-position: 6135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev Content-Length: 750 Lines: 33 --PNpeiK4tTqhYOExY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 18, 2004 at 11:03:50AM -0700, Stephen Hemminger wrote: > Minor stuff. All valid. I'll clean them up in the next pass. Thanks, Matt --=20 Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com --PNpeiK4tTqhYOExY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA00MqIavu95Lw/AkRAhy1AJ9FxlMW1qRiB85qg6Nu7fF/HIO1rQCeJBbL LYZqj7t8UQL7stY0Lnm8lR8= =ZYV/ -----END PGP SIGNATURE----- --PNpeiK4tTqhYOExY-- From romieu@fr.zoreil.com Fri Jun 18 13:10:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:10:43 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKAcgi004835 for ; Fri, 18 Jun 2004 13:10:40 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5IKAEon020209; Fri, 18 Jun 2004 22:10:14 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5IKAEag020208; Fri, 18 Jun 2004 22:10:14 +0200 Date: Fri, 18 Jun 2004 22:10:14 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-rc3-mm2 1/5] via-velocity: PCI ID move Message-ID: <20040618221014.A15640@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 6136 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: 2064 Lines: 47 (Note: this serie requires a -mm based kernel as the via-velocity patches are not included in Jeff's -netdev patches). PCI ID moved from the driver to the kernel database. A change for the pci.ids file project at souceforge has been submitted as well. diff -puN drivers/net/via-velocity.c~via-velocity-20 drivers/net/via-velocity.c --- linux-2.6.7-rc3/drivers/net/via-velocity.c~via-velocity-20 2004-06-18 21:24:53.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.c 2004-06-18 21:32:01.000000000 +0200 @@ -290,8 +290,9 @@ static struct velocity_info_tbl chip_inf */ static struct pci_device_id velocity_id_table[] __devinitdata = { - {0x1106, 0x3119, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (unsigned long) &chip_info_table[0]}, - {0,} + {PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_612X, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, (unsigned long) chip_info_table}, + {0, } }; MODULE_DEVICE_TABLE(pci, velocity_id_table); diff -puN include/linux/pci_ids.h~via-velocity-20 include/linux/pci_ids.h --- linux-2.6.7-rc3/include/linux/pci_ids.h~via-velocity-20 2004-06-18 21:24:53.000000000 +0200 +++ linux-2.6.7-rc3-fr/include/linux/pci_ids.h 2004-06-18 21:24:53.000000000 +0200 @@ -1214,6 +1214,7 @@ #define PCI_DEVICE_ID_VIA_8233C_0 0x3109 #define PCI_DEVICE_ID_VIA_8361 0x3112 #define PCI_DEVICE_ID_VIA_XM266 0x3116 +#define PCI_DEVICE_ID_VIA_612X 0x3119 #define PCI_DEVICE_ID_VIA_862X_0 0x3123 #define PCI_DEVICE_ID_VIA_8753_0 0x3128 #define PCI_DEVICE_ID_VIA_8233A 0x3147 diff -puN drivers/net/via-velocity.h~via-velocity-20 drivers/net/via-velocity.h --- linux-2.6.7-rc3/drivers/net/via-velocity.h~via-velocity-20 2004-06-18 21:24:53.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.h 2004-06-18 21:32:00.000000000 +0200 @@ -37,7 +37,6 @@ #define OPTION_DEFAULT { [0 ... MAX_UNITS-1] = -1} #define REV_ID_VT6110 (0) -#define DEVICE_ID (0x3119) #define BYTE_REG_BITS_ON(x,p) do { writeb(readb((p))|(x),(p));} while (0) #define WORD_REG_BITS_ON(x,p) do { writew(readw((p))|(x),(p));} while (0) _ From romieu@fr.zoreil.com Fri Jun 18 13:14:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:14:40 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKEagi005227 for ; Fri, 18 Jun 2004 13:14:37 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5IKBgon020220; Fri, 18 Jun 2004 22:11:42 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5IKBgYG020219; Fri, 18 Jun 2004 22:11:42 +0200 Date: Fri, 18 Jun 2004 22:11:42 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-rc3-mm2 2/5] via-velocity: uniformize use of OWNED_BY_NIC Message-ID: <20040618221142.A20210@electric-eye.fr.zoreil.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.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: <20040618221014.A15640@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Fri, Jun 18, 2004 at 10:10:14PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6137 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: 1575 Lines: 50 Introduce velocity_give_rx_desc() to uniformize the use of OWNED_BY_NIC through the driver. diff -puN drivers/net/via-velocity.c~via-velocity-30 drivers/net/via-velocity.c --- linux-2.6.7-rc3/drivers/net/via-velocity.c~via-velocity-30 2004-06-18 21:34:14.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.c 2004-06-18 21:34:14.000000000 +0200 @@ -465,6 +465,12 @@ static void velocity_init_cam_filter(str } } +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 @@ -485,7 +491,7 @@ static void velocity_rx_reset(struct vel * Init state, all RD entries belong to the NIC */ for (i = 0; i < vptr->options.numrx; ++i) - vptr->rd_ring[i].rdesc0.owner = cpu_to_le32(OWNED_BY_NIC); + velocity_give_rx_desc(vptr->rd_ring + i); writew(vptr->options.numrx, ®s->RBRDU); writel(vptr->rd_pool_dma, ®s->RDBaseLo); @@ -1008,7 +1014,7 @@ static int velocity_init_rd_ring(struct velocity_free_rd_ring(vptr); goto out; } - rd->rdesc0.owner = OWNED_BY_NIC; + velocity_give_rx_desc(rd); } vptr->rd_used = vptr->rd_curr = 0; out: @@ -1205,8 +1211,7 @@ static int velocity_rx_srv(struct veloci if (--rd_prev < 0) rd_prev = vptr->options.numrx - 1; - rd = &(vptr->rd_ring[rd_prev]); - rd->rdesc0.owner = OWNED_BY_NIC; + velocity_give_rx_desc(vptr->rd_ring + rd_prev); } writew(4, &(regs->RBRDU)); vptr->rd_used -= 4; _ From romieu@fr.zoreil.com Fri Jun 18 13:14:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:14:43 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKEbgi005228 for ; Fri, 18 Jun 2004 13:14:40 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5IKDaon020241; Fri, 18 Jun 2004 22:13:36 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5IKDaVM020240; Fri, 18 Jun 2004 22:13:36 +0200 Date: Fri, 18 Jun 2004 22:13:36 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-rc3-mm2 3/5] via-velocity: velocity_receive_frame diets Message-ID: <20040618221336.B20210@electric-eye.fr.zoreil.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <20040618221142.A20210@electric-eye.fr.zoreil.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: <20040618221142.A20210@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Fri, Jun 18, 2004 at 10:11:42PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6138 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: 2314 Lines: 75 Weight loss in velocity_receive_frame(): - isolate the ip header alignment tsk from velocity_receive_frame(); - following p.30 of the datasheet, rdesc0.len includes the CRC length: the amount of data copied during the ip alignment can be shortened. diff -puN drivers/net/via-velocity.c~via-velocity-40 drivers/net/via-velocity.c --- linux-2.6.7-rc3/drivers/net/via-velocity.c~via-velocity-40 2004-06-18 21:38:59.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.c 2004-06-18 21:58:58.000000000 +0200 @@ -1255,6 +1255,28 @@ static inline void velocity_rx_csum(stru } /** + * velocity_iph_realign - IP header alignment + * @vptr: velocity we are handling + * @skb: network layer packet buffer + * @pkt_size: received data size + * + * Align IP header on a 2 bytes boundary. This behavior can be + * configured by the user. + */ +static inline void velocity_iph_realign(struct velocity_info *vptr, + struct sk_buff *skb, int pkt_size) +{ + /* FIXME - memmove ? */ + if (vptr->flags & VELOCITY_FLAGS_IP_ALIGN) { + int i; + + for (i = pkt_size; i >= 0; i--) + *(skb->data + i + 2) = *(skb->data + i); + skb_reserve(skb, 2); + } +} + +/** * velocity_receive_frame - received packet processor * @vptr: velocity we are handling * @idx: ring index @@ -1268,6 +1290,7 @@ static int velocity_receive_frame(struct struct net_device_stats *stats = &vptr->stats; struct velocity_rd_info *rd_info = &(vptr->rd_info[idx]); struct rx_desc *rd = &(vptr->rd_ring[idx]); + int pkt_len = rd->rdesc0.len; struct sk_buff *skb; if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) { @@ -1287,16 +1310,9 @@ static int velocity_receive_frame(struct rd_info->skb_dma = (dma_addr_t) NULL; rd_info->skb = NULL; - /* FIXME - memmove ? */ - if (vptr->flags & VELOCITY_FLAGS_IP_ALIGN) { - int i; - for (i = rd->rdesc0.len + 4; i >= 0; i--) - *(skb->data + i + 2) = *(skb->data + i); - skb->data += 2; - skb->tail += 2; - } + velocity_iph_realign(vptr, skb, pkt_len); - skb_put(skb, (rd->rdesc0.len - 4)); + skb_put(skb, pkt_len - 4); skb->protocol = eth_type_trans(skb, skb->dev); /* @@ -1316,7 +1332,7 @@ static int velocity_receive_frame(struct * FIXME: need rx_copybreak handling */ - stats->rx_bytes += skb->len; + stats->rx_bytes += pkt_len; netif_rx(skb); return 0; _ From romieu@fr.zoreil.com Fri Jun 18 13:18:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:18:45 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKIegi005910 for ; Fri, 18 Jun 2004 13:18:41 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5IKGIon020412; Fri, 18 Jun 2004 22:16:18 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5IKGIkl020411; Fri, 18 Jun 2004 22:16:18 +0200 Date: Fri, 18 Jun 2004 22:16:18 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-rc3-mm2 5/5] via-velocity: Rx copybreak Message-ID: <20040618221618.D20210@electric-eye.fr.zoreil.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <20040618221142.A20210@electric-eye.fr.zoreil.com> <20040618221336.B20210@electric-eye.fr.zoreil.com> <20040618221444.C20210@electric-eye.fr.zoreil.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: <20040618221444.C20210@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Fri, Jun 18, 2004 at 10:14:44PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6139 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: 5337 Lines: 166 Handle copybreak. - velocity_rx_refill() is modified to allow the processing of a Rx desc ring wherein the empty skb slots are not necessarily contiguous. Given the preceeding changes, rx_copybreak should not need anything else; - the driver does not rely on rd_info->skb_dma set to NULL any more; - a few pci_dma_sync_single_for_{cpu/device} changes; - more function documentation. Some inspiration has been taken from similar r8169 code. diff -puN drivers/net/via-velocity.c~via-velocity-60 drivers/net/via-velocity.c --- linux-2.6.7-rc3/drivers/net/via-velocity.c~via-velocity-60 2004-06-18 21:58:49.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.c 2004-06-18 21:58:49.000000000 +0200 @@ -226,6 +226,10 @@ VELOCITY_PARAM(wol_opts, "Wake On Lan op VELOCITY_PARAM(int_works, "Number of packets per interrupt services"); +static int rx_copybreak = 200; +MODULE_PARM(rx_copybreak, "i"); +MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for copy-only-tiny-frames"); + static int velocity_found1(struct pci_dev *pdev, const struct pci_device_id *ent); static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr, struct velocity_info_tbl *info); static int velocity_get_pci_info(struct velocity_info *, struct pci_dev *pdev); @@ -1007,13 +1011,22 @@ static int velocity_rx_refill(struct vel { int dirty = vptr->rd_dirty, done = 0, ret = 0; - while (!vptr->rd_info[dirty].skb) { - ret = velocity_alloc_rx_buf(vptr, dirty); - if (ret < 0) + do { + 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)) break; + + if (!vptr->rd_info[dirty].skb) { + ret = velocity_alloc_rx_buf(vptr, dirty); + if (ret < 0) + break; + } done++; dirty = (dirty < vptr->options.numrx - 1) ? dirty + 1 : 0; - } + } while (dirty != vptr->rd_curr); + if (done) { vptr->rd_dirty = dirty; vptr->rd_filled += done; @@ -1072,7 +1085,7 @@ static void velocity_free_rd_ring(struct for (i = 0; i < vptr->options.numrx; i++) { struct velocity_rd_info *rd_info = &(vptr->rd_info[i]); - if (!rd_info->skb_dma) + if (!rd_info->skb) continue; pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx_buf_sz, PCI_DMA_FROMDEVICE); @@ -1208,7 +1221,6 @@ static int velocity_rx_srv(struct veloci /* * Don't drop CE or RL error frame although RXOK is off - * FIXME: need to handle copybreak */ if ((rd->rdesc0.RSR & RSR_RXOK) || (!(rd->rdesc0.RSR & RSR_RXOK) && (rd->rdesc0.RSR & (RSR_CE | RSR_RL)))) { if (velocity_receive_frame(vptr, rd_curr) < 0) @@ -1268,6 +1280,43 @@ static inline void velocity_rx_csum(stru } /** + * velocity_rx_copy - in place Rx copy for small packets + * @rx_skb: network layer packet buffer candidate + * @pkt_size: received data size + * @rd: receive packet descriptor + * @dev: network device + * + * Replace the current skb that is scheduled for Rx processing by a + * shorter, immediatly allocated skb, if the received packet is small + * enough. This function returns a negative value if the received + * packet is too big or if memory is exhausted. + */ +static inline int velocity_rx_copy(struct sk_buff **rx_skb, int pkt_size, + struct velocity_info *vptr) +{ + int ret = -1; + + if (pkt_size < rx_copybreak) { + struct sk_buff *new_skb; + + new_skb = dev_alloc_skb(pkt_size + 2); + if (new_skb) { + new_skb->dev = vptr->dev; + new_skb->ip_summed = rx_skb[0]->ip_summed; + + if (vptr->flags & VELOCITY_FLAGS_IP_ALIGN) + skb_reserve(new_skb, 2); + + memcpy(new_skb->data, rx_skb[0]->tail, pkt_size); + *rx_skb = new_skb; + ret = 0; + } + + } + return ret; +} + +/** * velocity_iph_realign - IP header alignment * @vptr: velocity we are handling * @skb: network layer packet buffer @@ -1300,6 +1349,7 @@ static inline void velocity_iph_realign( static int velocity_receive_frame(struct velocity_info *vptr, int idx) { + void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int); struct net_device_stats *stats = &vptr->stats; struct velocity_rd_info *rd_info = &(vptr->rd_info[idx]); struct rx_desc *rd = &(vptr->rd_ring[idx]); @@ -1318,15 +1368,8 @@ static int velocity_receive_frame(struct skb = rd_info->skb; skb->dev = vptr->dev; - pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx_buf_sz, - PCI_DMA_FROMDEVICE); - rd_info->skb_dma = (dma_addr_t) NULL; - rd_info->skb = NULL; - - velocity_iph_realign(vptr, skb, pkt_len); - - skb_put(skb, pkt_len - 4); - skb->protocol = eth_type_trans(skb, skb->dev); + pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma, + vptr->rx_buf_sz, PCI_DMA_FROMDEVICE); /* * Drop frame not meeting IEEE 802.3 @@ -1339,11 +1382,21 @@ static int velocity_receive_frame(struct } } + pci_action = pci_dma_sync_single_for_device; + velocity_rx_csum(rd, skb); - /* - * FIXME: need rx_copybreak handling - */ + if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) { + velocity_iph_realign(vptr, skb, pkt_len); + pci_action = pci_unmap_single; + rd_info->skb = NULL; + } + + pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx_buf_sz, + PCI_DMA_FROMDEVICE); + + skb_put(skb, pkt_len - 4); + skb->protocol = eth_type_trans(skb, skb->dev); stats->rx_bytes += pkt_len; netif_rx(skb); _ From romieu@fr.zoreil.com Fri Jun 18 13:18:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:18:46 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKIfgi005912 for ; Fri, 18 Jun 2004 13:18:42 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5IKEion020360; Fri, 18 Jun 2004 22:14:45 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5IKEiWM020350; Fri, 18 Jun 2004 22:14:44 +0200 Date: Fri, 18 Jun 2004 22:14:44 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-rc3-mm2 4/5] via-velocity: Rx buffers allocation rework Message-ID: <20040618221444.C20210@electric-eye.fr.zoreil.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <20040618221142.A20210@electric-eye.fr.zoreil.com> <20040618221336.B20210@electric-eye.fr.zoreil.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: <20040618221336.B20210@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Fri, Jun 18, 2004 at 10:13:36PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6140 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: 6291 Lines: 205 Rework of the Rx buffers allocation: - Rx irq handler (velocity_rx_srv): defer the Rx buffer allocation until the packet processing loop is done; - a separate index related to the Rx descriptor ("rd_dirty") is introduced to distinguish the first Rx descriptor whose buffer has to be refilled. This way the driver does not need to confuse this descriptor with the most recently netif()ed one. Rationale: batch + rx_copybreak; - dirty/empty Rx descriptors are identified through the whole driver via an adequate NULL pointer in the velocity_rd_info[] array (see velocity_rx_refill() and velocity_receive_frame()); - Rx descriptors need to be grouped by a multiple of 4 before they can be handed back to the asic (hardware constraint). This task is moved from the Rx processing loop to the Rx refill function; - factorization of code in velocity_init_rd_ring(). diff -puN drivers/net/via-velocity.c~via-velocity-50 drivers/net/via-velocity.c --- linux-2.6.7-rc3/drivers/net/via-velocity.c~via-velocity-50 2004-06-18 21:56:21.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.c 2004-06-18 21:56:21.000000000 +0200 @@ -485,7 +485,7 @@ static void velocity_rx_reset(struct vel struct mac_regs * regs = vptr->mac_regs; int i; - vptr->rd_used = vptr->rd_curr = 0; + vptr->rd_dirty = vptr->rd_filled = vptr->rd_curr = 0; /* * Init state, all RD entries belong to the NIC @@ -980,6 +980,49 @@ static void velocity_free_rings(struct v pci_free_consistent(vptr->pdev, size, vptr->tx_bufs, vptr->tx_bufs_dma); } +static inline void velocity_give_many_rx_descs(struct velocity_info *vptr) +{ + struct mac_regs *regs = vptr->mac_regs; + int avail, dirty, unusable; + + /* + * RD number must be equal to 4X per hardware spec + * (programming guide rev 1.20, p.13) + */ + if (vptr->rd_filled < 4) + return; + + unusable = vptr->rd_filled | 0x0003; + 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); + } + + writew(vptr->rd_filled & 0xfffc, ®s->RBRDU); + vptr->rd_filled = unusable; +} + +static int velocity_rx_refill(struct velocity_info *vptr) +{ + int dirty = vptr->rd_dirty, done = 0, ret = 0; + + while (!vptr->rd_info[dirty].skb) { + ret = velocity_alloc_rx_buf(vptr, dirty); + if (ret < 0) + break; + done++; + dirty = (dirty < vptr->options.numrx - 1) ? dirty + 1 : 0; + } + if (done) { + vptr->rd_dirty = dirty; + vptr->rd_filled += done; + velocity_give_many_rx_descs(vptr); + } + + return ret; +} + /** * velocity_init_rd_ring - set up receive ring * @vptr: velocity to configure @@ -990,9 +1033,7 @@ static void velocity_free_rings(struct v static int velocity_init_rd_ring(struct velocity_info *vptr) { - int i, ret = -ENOMEM; - struct rx_desc *rd; - struct velocity_rd_info *rd_info; + int ret = -ENOMEM; unsigned int rsize = sizeof(struct velocity_rd_info) * vptr->options.numrx; @@ -1001,22 +1042,14 @@ static int velocity_init_rd_ring(struct goto out; memset(vptr->rd_info, 0, rsize); - /* Init the RD ring entries */ - for (i = 0; i < vptr->options.numrx; i++) { - rd = &(vptr->rd_ring[i]); - rd_info = &(vptr->rd_info[i]); + vptr->rd_filled = vptr->rd_dirty = vptr->rd_curr = 0; - ret = velocity_alloc_rx_buf(vptr, i); - if (ret < 0) { - VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR - "%s: failed to allocate RX buffer.\n", - vptr->dev->name); - velocity_free_rd_ring(vptr); - goto out; - } - velocity_give_rx_desc(rd); + ret = velocity_rx_refill(vptr); + if (ret < 0) { + VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR + "%s: failed to allocate RX buffer.\n", vptr->dev->name); + velocity_free_rd_ring(vptr); } - vptr->rd_used = vptr->rd_curr = 0; out: return ret; } @@ -1160,22 +1193,14 @@ static void velocity_free_td_ring(struct static int velocity_rx_srv(struct velocity_info *vptr, int status) { - struct rx_desc *rd; struct net_device_stats *stats = &vptr->stats; - struct mac_regs * regs = vptr->mac_regs; int rd_curr = vptr->rd_curr; int works = 0; while (1) { + struct rx_desc *rd = vptr->rd_ring + rd_curr; - rd = &(vptr->rd_ring[rd_curr]); - - if ((vptr->rd_info[rd_curr]).skb == NULL) { - if (velocity_alloc_rx_buf(vptr, rd_curr) < 0) - break; - } - - if (works++ > 15) + if (!vptr->rd_info[rd_curr].skb || (works++ > 15)) break; if (rd->rdesc0.owner == OWNED_BY_NIC) @@ -1186,14 +1211,8 @@ static int velocity_rx_srv(struct veloci * FIXME: need to handle copybreak */ if ((rd->rdesc0.RSR & RSR_RXOK) || (!(rd->rdesc0.RSR & RSR_RXOK) && (rd->rdesc0.RSR & (RSR_CE | RSR_RL)))) { - if (velocity_receive_frame(vptr, rd_curr) == 0) { - if (velocity_alloc_rx_buf(vptr, rd_curr) < 0) { - VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR "%s: can not allocate rx buf\n", vptr->dev->name); - break; - } - } else { + if (velocity_receive_frame(vptr, rd_curr) < 0) stats->rx_dropped++; - } } else { if (rd->rdesc0.RSR & RSR_CRC) stats->rx_crc_errors++; @@ -1205,24 +1224,18 @@ static int velocity_rx_srv(struct veloci rd->inten = 1; - if (++vptr->rd_used >= 4) { - int i, rd_prev = rd_curr; - for (i = 0; i < 4; i++) { - if (--rd_prev < 0) - rd_prev = vptr->options.numrx - 1; - - velocity_give_rx_desc(vptr->rd_ring + rd_prev); - } - writew(4, &(regs->RBRDU)); - vptr->rd_used -= 4; - } - vptr->dev->last_rx = jiffies; rd_curr++; if (rd_curr >= vptr->options.numrx) rd_curr = 0; } + + if (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; diff -puN drivers/net/via-velocity.h~via-velocity-50 drivers/net/via-velocity.h --- linux-2.6.7-rc3/drivers/net/via-velocity.h~via-velocity-50 2004-06-18 21:56:21.000000000 +0200 +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.h 2004-06-18 21:56:21.000000000 +0200 @@ -1771,7 +1771,8 @@ struct velocity_info { struct velocity_td_info *td_infos[TX_QUEUE_NO]; int rd_curr; - int rd_used; + int rd_dirty; + u32 rd_filled; struct rx_desc *rd_ring; struct velocity_rd_info *rd_info; /* It's an array */ _ From davem@redhat.com Fri Jun 18 13:28:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:28:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKS4gi006943 for ; Fri, 18 Jun 2004 13:28:05 -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 i5IKRre1001534; Fri, 18 Jun 2004 16:27:53 -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 i5IKRr019142; Fri, 18 Jun 2004 16:27:53 -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 i5IKRYPd031374; Fri, 18 Jun 2004 16:27:34 -0400 Date: Fri, 18 Jun 2004 13:27:11 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH] (1/4) delay scheduler enqueue always succeeds. Message-Id: <20040618132711.6784b460.davem@redhat.com> In-Reply-To: <20040617155556.5f53dff0@dell_ss3.pdx.osdl.net> References: <20040617155556.5f53dff0@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6142 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: 7 On Thu, 17 Jun 2004 15:55:56 -0700 Stephen Hemminger wrote: > If underlying fifo enqueue fails, return the status not 0. > Same patch should apply to both 2.6 and 2.4 Duh :) Applied, thanks Stephen. From kuznet@ms2.inr.ac.ru Fri Jun 18 13:28:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:28:32 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKSQgi007019 for ; Fri, 18 Jun 2004 13:28:27 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id AAA03080; Sat, 19 Jun 2004 00:25:51 +0400 Date: Sat, 19 Jun 2004 00:25:51 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040618202551.GA2733@ms2.inr.ac.ru> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617213832.GC14089@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 1477 Lines: 36 Hello! > > >From another hand, if it is an ICMP from beyond another end of tunnel, > > it is problem of original senders to handle them. Gateways even do not > > see such ICMPs, which are destined not for them. > > Agreed. But this falls apart when the gateway is the original sender :) I see now. It is really another missing link. The case when we are gateway and sender from the same address altogether is missed. Well, I think they are just to be reflected directly in dst->pmtu. Apparently, incoming ICMPs are to be run not only through raw IP dsts but also though policy to find matching bundles and make dst->pmtu = min(new_pmtu, dst->pmtu) on them. > that within each bundle, the MTU may still differ depending on the > final destination address. It is not _within_. Bundles are created per address pair, in your case 192.168.0.2 -> 10.10.10.10 should be a separate bundle. Even if we will start to do more aggressive aggregation, pmtu discovery must result in cloning, compare with raw IPv6, where pmtu discovery causes cloning of routes with prefix length < 128. Actually, this even does not change things comparing to existing understanding (not the code though :-(), because after we start to collect pmtu on SAs, we have to recalculate dst->pmtu too, it would be kind of expensive to run through bundle and take minimum of all the dst->pmtu-overhead_at_this_level for each packet, so we have to precalculate the result and store it at top level. Alexey From akepner@sgi.com Fri Jun 18 13:28:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:28:42 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKSTgi007012 for ; Fri, 18 Jun 2004 13:28:29 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5IKHjhv018620 for ; Fri, 18 Jun 2004 13:17:45 -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 i5IKQQkL008108 for ; Fri, 18 Jun 2004 13:26:26 -0700 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i5IKHDCe17708338; Fri, 18 Jun 2004 13:17:28 -0700 (PDT) Date: Fri, 18 Jun 2004 13:12:23 -0700 From: Arthur Kepner X-X-Sender: akepner@neteng.engr.sgi.com To: Andi Kleen cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] lockless loopback patch for 2.6 (version 2) In-Reply-To: <20040614182331.GA11862@wotan.suse.de> Message-ID: References: <20040614182331.GA11862@wotan.suse.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1072017398-1205407494-1087589543=:955203" X-archive-position: 6144 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: 16097 Lines: 335 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. ---1072017398-1205407494-1087589543=:955203 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Jun 2004, Andi Kleen wrote: > > +#define LOOPBACK_STAT_INC(field) \ > > + (per_cpu_ptr(loopback_stats, smp_processor_id())->field++) > > +#define LOOPBACK_STAT_ADD(field, n) \ > > + (per_cpu_ptr(loopback_stats, smp_processor_id())->field += n) > > This is too complicated and not preempt safe. Use > __get_cpu_var(loopback_stats).field++; This is too complicated (and preemptible). But I think you mean to use: get_cpu_ptr(loopback_stats)->field1 += blah; get_cpu_ptr(loopback_stats)->field2++; .... put_cpu_var(loopback_stats); (loopback_stats is allocated with alloc_percpu().) > > I would also remove the macros and do this directly. With this simplification the macros are not helpful. I'll kill 'em. > > > + struct net_device_stats *stats = dev->priv; > > + int i; > > + > > + if (unlikely(!stats)) { > > Tests for NULL don't need an unlikely, because gcc does that by > default for itself. OK, I didn't know that. > But why can the stats here be NULL anyways? > stats can be NULL. loopback_init() might have failed when it tried to kmalloc() it. > > #ifdef CONFIG_NET_RADIO > > #include /* Note : will define WIRELESS_EXT */ > > #include > > @@ -1277,6 +1278,20 @@ > > return 0; > > } > > > > +#define HARD_TX_LOCK_BH(dev, cpu) { \ > > + if ( dev->features && NETIF_F_LLTX == 0 ) { \ > > && instead of & and missing brackets. > .... Fixed (both instances.) > > > - if (ops->reset) > > - ops->reset(qdisc); > > - if (ops->destroy) > > - ops->destroy(qdisc); > > - module_put(ops->owner); > > - if (!(qdisc->flags&TCQ_F_BUILTIN)) > > - kfree(qdisc); > > + > > + call_rcu(&qdisc->q_rcu, __qdisc_destroy, qdisc); > > I think you need at least a wmb() after > > if (q == qdisc) { > *qp = q->next; > break; > } > > Otherwise the order of updates to the readers is no guaranteed. > Also if you want to support alpha there will need to be > smp_read_barrier_depends() in the reader walking this list. Hmmm, I'm not sure. The only place where the struct Qdisc is accessed locklessly is in dev_queue_xmit(). (Or at least that's the only place where the locking behavior when accessing the Qdisc _changes_ with this patch.) It *does* look as if a smp_read_barrier_depends() is appropriate in dev_queue_xmit() as follows: rcu_read_lock(); .... q = dev->qdisc; + smp_read_barrier_depends(); if (q->enqueue) { .... spin_lock_bh(&dev->queue_lock); rc = q->enqueue(skb, q); qdisc_run(dev); spin_unlock_bh(&dev->queue_lock); .... } rcu_read_unlock(); Also, there should be a memory barrier after the Qdisc's "enqueue" pointer is modified but before the netdevice's qdisc pointer is modified (although it looks as if there's always a spinlock acquisition which does this implicitly.) But I've added the smp_wmb()s to qdisc_create() and qdisc_create_dflt() to be safe. A patch with these changes is attached. -- Arthur ---1072017398-1205407494-1087589543=:955203 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="lockless_loopback.patch.3" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: lockless loopback patch 3 Content-Disposition: attachment; filename="lockless_loopback.patch.3" LS0tIGxpbnV4Lm9yaWcvZHJpdmVycy9uZXQvbG9vcGJhY2suYwkyMDA0LTA2 LTA4IDE1OjM2OjUwLjAwMDAwMDAwMCAtMDcwMA0KKysrIGxpbnV4L2RyaXZl cnMvbmV0L2xvb3BiYWNrLmMJMjAwNC0wNi0xNSAxNTozOTo1Ni4wMDAwMDAw MDAgLTA3MDANCkBAIC01Niw2ICs1Niw3IEBADQogI2luY2x1ZGUgPGxpbnV4 L2lwLmg+DQogI2luY2x1ZGUgPGxpbnV4L3RjcC5oPg0KIA0KK3N0YXRpYyBz dHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqbG9vcGJhY2tfc3RhdHM7DQogDQog I2RlZmluZSBMT09QQkFDS19PVkVSSEVBRCAoMTI4ICsgTUFYX0hFQURFUiAr IDE2ICsgMTYpDQogDQpAQCAtMTIzLDcgKzEyNCw2IEBADQogICovDQogc3Rh dGljIGludCBsb29wYmFja194bWl0KHN0cnVjdCBza19idWZmICpza2IsIHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYpDQogew0KLQlzdHJ1Y3QgbmV0X2Rldmlj ZV9zdGF0cyAqc3RhdHMgPSBkZXYtPnByaXY7DQogDQogCXNrYl9vcnBoYW4o c2tiKTsNCiANCkBAIC0xNDIsMTEgKzE0MiwxMiBAQA0KIAl9DQogDQogCWRl di0+bGFzdF9yeCA9IGppZmZpZXM7DQotCWlmIChsaWtlbHkoc3RhdHMpKSB7 DQotCQlzdGF0cy0+cnhfYnl0ZXMrPXNrYi0+bGVuOw0KLQkJc3RhdHMtPnR4 X2J5dGVzKz1za2ItPmxlbjsNCi0JCXN0YXRzLT5yeF9wYWNrZXRzKys7DQot CQlzdGF0cy0+dHhfcGFja2V0cysrOw0KKwlpZiAobGlrZWx5KGxvb3BiYWNr X3N0YXRzKSkgew0KKwkJZ2V0X2NwdV9wdHIobG9vcGJhY2tfc3RhdHMpLT5y eF9ieXRlcyArPSBza2ItPmxlbjsNCisJCWdldF9jcHVfcHRyKGxvb3BiYWNr X3N0YXRzKS0+dHhfYnl0ZXMgKz0gc2tiLT5sZW47DQorCQlnZXRfY3B1X3B0 cihsb29wYmFja19zdGF0cyktPnJ4X3BhY2tldHMrKzsNCisJCWdldF9jcHVf cHRyKGxvb3BiYWNrX3N0YXRzKS0+dHhfcGFja2V0cysrOw0KKwkJcHV0X2Nw dV9wdHIobG9vcGJhY2tfc3RhdHMpOw0KIAl9DQogDQogCW5ldGlmX3J4KHNr Yik7DQpAQCAtMTU2LDcgKzE1NywyOCBAQA0KIA0KIHN0YXRpYyBzdHJ1Y3Qg bmV0X2RldmljZV9zdGF0cyAqZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNl ICpkZXYpDQogew0KLQlyZXR1cm4gKHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRz ICopZGV2LT5wcml2Ow0KKwlzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqc3Rh dHMgPSBkZXYtPnByaXY7DQorCWludCBpOw0KKw0KKwlpZiAoIXN0YXRzKSB7 DQorCQlyZXR1cm4gTlVMTDsNCisJfQ0KKw0KKwltZW1zZXQoc3RhdHMsIDAs IHNpemVvZihzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cykpOw0KKwlpZiAoIWxv b3BiYWNrX3N0YXRzKSB7DQorCQlyZXR1cm4gc3RhdHM7DQorCX0NCisNCisJ Zm9yIChpPTA7IGkgPCBOUl9DUFVTOyBpKyspIHsNCisJCWlmICghY3B1X3Bv c3NpYmxlKGkpKSANCisJCQljb250aW51ZTsNCisJCXN0YXRzLT5yeF9ieXRl cyAgICs9IHBlcl9jcHVfcHRyKGxvb3BiYWNrX3N0YXRzLCBpKS0+cnhfYnl0 ZXM7DQorCQlzdGF0cy0+dHhfYnl0ZXMgICArPSBwZXJfY3B1X3B0cihsb29w YmFja19zdGF0cywgaSktPnR4X2J5dGVzOw0KKwkJc3RhdHMtPnJ4X3BhY2tl dHMgKz0gcGVyX2NwdV9wdHIobG9vcGJhY2tfc3RhdHMsIGkpLT5yeF9wYWNr ZXRzOw0KKwkJc3RhdHMtPnR4X3BhY2tldHMgKz0gcGVyX2NwdV9wdHIobG9v cGJhY2tfc3RhdHMsIGkpLT50eF9wYWNrZXRzOw0KKwl9DQorCQkJCQ0KKwly ZXR1cm4gc3RhdHM7DQogfQ0KIA0KIHN0cnVjdCBuZXRfZGV2aWNlIGxvb3Bi YWNrX2RldiA9IHsNCkBAIC0xNzMsNyArMTk1LDggQEANCiAJLnJlYnVpbGRf aGVhZGVyCQk9IGV0aF9yZWJ1aWxkX2hlYWRlciwNCiAJLmZsYWdzCQkJPSBJ RkZfTE9PUEJBQ0ssDQogCS5mZWF0dXJlcyAJCT0gTkVUSUZfRl9TR3xORVRJ Rl9GX0ZSQUdMSVNUDQotCQkJCSAgfE5FVElGX0ZfTk9fQ1NVTXxORVRJRl9G X0hJR0hETUEsDQorCQkJCSAgfE5FVElGX0ZfTk9fQ1NVTXxORVRJRl9GX0hJ R0hETUENCisJCQkJICB8TkVUSUZfRl9MTFRYLA0KIH07DQogDQogLyogU2V0 dXAgYW5kIHJlZ2lzdGVyIHRoZSBvZiB0aGUgTE9PUEJBQ0sgZGV2aWNlLiAq Lw0KQEAgLTE4OCw2ICsyMTEsOCBAQA0KIAkJbG9vcGJhY2tfZGV2LnByaXYg PSBzdGF0czsNCiAJCWxvb3BiYWNrX2Rldi5nZXRfc3RhdHMgPSAmZ2V0X3N0 YXRzOw0KIAl9DQorDQorCWxvb3BiYWNrX3N0YXRzID0gYWxsb2NfcGVyY3B1 KHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzKTsNCiAJDQogCXJldHVybiByZWdp c3Rlcl9uZXRkZXYoJmxvb3BiYWNrX2Rldik7DQogfTsNCi0tLSBsaW51eC5v cmlnL2luY2x1ZGUvbGludXgvbmV0ZGV2aWNlLmgJMjAwNC0wNi0wOCAxNToz Njo1MS4wMDAwMDAwMDAgLTA3MDANCisrKyBsaW51eC9pbmNsdWRlL2xpbnV4 L25ldGRldmljZS5oCTIwMDQtMDYtMTQgMDk6MjA6MjYuMDAwMDAwMDAwIC0w NzAwDQpAQCAtNDAzLDYgKzQwMyw3IEBADQogI2RlZmluZSBORVRJRl9GX0hX X1ZMQU5fRklMVEVSCTUxMgkvKiBSZWNlaXZlIGZpbHRlcmluZyBvbiBWTEFO ICovDQogI2RlZmluZSBORVRJRl9GX1ZMQU5fQ0hBTExFTkdFRAkxMDI0CS8q IERldmljZSBjYW5ub3QgaGFuZGxlIFZMQU4gcGFja2V0cyAqLw0KICNkZWZp bmUgTkVUSUZfRl9UU08JCTIwNDgJLyogQ2FuIG9mZmxvYWQgVENQL0lQIHNl Z21lbnRhdGlvbiAqLw0KKyNkZWZpbmUgTkVUSUZfRl9MTFRYCQk0MDk2CS8q IExvY2tMZXNzIFRYICovDQogDQogCS8qIENhbGxlZCBhZnRlciBkZXZpY2Ug aXMgZGV0YWNoZWQgZnJvbSBuZXR3b3JrLiAqLw0KIAl2b2lkCQkJKCp1bmlu aXQpKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOw0KLS0tIGxpbnV4Lm9yaWcv aW5jbHVkZS9uZXQvcGt0X3NjaGVkLmgJMjAwNC0wNi0wOCAxNTozNjo1MS4w MDAwMDAwMDAgLTA3MDANCisrKyBsaW51eC9pbmNsdWRlL25ldC9wa3Rfc2No ZWQuaAkyMDA0LTA2LTExIDEzOjQ2OjI1LjAwMDAwMDAwMCAtMDcwMA0KQEAg LTExLDYgKzExLDcgQEANCiAjaW5jbHVkZSA8bGludXgvbmV0ZGV2aWNlLmg+ DQogI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+DQogI2luY2x1ZGUgPGxpbnV4 L3BrdF9zY2hlZC5oPg0KKyNpbmNsdWRlIDxsaW51eC9yY3VwZGF0ZS5oPg0K ICNpbmNsdWRlIDxuZXQvcGt0X2Nscy5oPg0KIA0KICNpZmRlZiBDT05GSUdf WDg2X1RTQw0KQEAgLTkyLDYgKzkzLDcgQEANCiAJc3RydWN0IG5ldF9kZXZp Y2UJKmRldjsNCiANCiAJc3RydWN0IHRjX3N0YXRzCQlzdGF0czsNCisJc3Ry dWN0IHJjdV9oZWFkIAlxX3JjdTsNCiAJaW50CQkJKCpyZXNoYXBlX2ZhaWwp KHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBRZGlzYyAqcSk7DQogDQog CS8qIFRoaXMgZmllbGQgaXMgZGVwcmVjYXRlZCwgYnV0IGl0IGlzIHN0aWxs IHVzZWQgYnkgQ0JRDQotLS0gbGludXgub3JpZy9uZXQvY29yZS9kZXYuYwky MDA0LTA2LTA4IDE1OjM2OjUzLjAwMDAwMDAwMCAtMDcwMA0KKysrIGxpbnV4 L25ldC9jb3JlL2Rldi5jCTIwMDQtMDYtMTUgMTY6MTk6MzkuMDAwMDAwMDAw IC0wNzAwDQpAQCAtMTA3LDYgKzEwNyw3IEBADQogI2luY2x1ZGUgPGxpbnV4 L21vZHVsZS5oPg0KICNpbmNsdWRlIDxsaW51eC9rYWxsc3ltcy5oPg0KICNp bmNsdWRlIDxsaW51eC9uZXRwb2xsLmg+DQorI2luY2x1ZGUgPGxpbnV4L3Jj dXBkYXRlLmg+DQogI2lmZGVmIENPTkZJR19ORVRfUkFESU8NCiAjaW5jbHVk ZSA8bGludXgvd2lyZWxlc3MuaD4JCS8qIE5vdGUgOiB3aWxsIGRlZmluZSBX SVJFTEVTU19FWFQgKi8NCiAjaW5jbHVkZSA8bmV0L2l3X2hhbmRsZXIuaD4N CkBAIC0xMjc3LDYgKzEyNzgsMjAgQEANCiAJcmV0dXJuIDA7DQogfQ0KIA0K KyNkZWZpbmUgSEFSRF9UWF9MT0NLX0JIKGRldiwgY3B1KSB7CQkJXA0KKwlp ZiAoKGRldi0+ZmVhdHVyZXMgJiBORVRJRl9GX0xMVFgpID09IDApIHsJXA0K KwkJc3Bpbl9sb2NrX2JoKCZkZXYtPnhtaXRfbG9jayk7CQlcDQorCQlkZXYt PnhtaXRfbG9ja19vd25lciA9IGNwdTsJCVwNCisJfQkJCQkJCVwNCit9DQor DQorI2RlZmluZSBIQVJEX1RYX1VOTE9DS19CSChkZXYpIHsJCQlcDQorCWlm ICgoZGV2LT5mZWF0dXJlcyAmIE5FVElGX0ZfTExUWCkgPT0gMCkgewlcDQor CQlkZXYtPnhtaXRfbG9ja19vd25lciA9IC0xOwkJXA0KKwkJc3Bpbl91bmxv Y2tfYmgoJmRldi0+eG1pdF9sb2NrKTsJXA0KKwl9CQkJCQkJXA0KK30NCisN CiAvKioNCiAgKglkZXZfcXVldWVfeG1pdCAtIHRyYW5zbWl0IGEgYnVmZmVy DQogICoJQHNrYjogYnVmZmVyIHRvIHRyYW5zbWl0DQpAQCAtMTMyMSwxOCAr MTMzNiwzNSBAQA0KIAkJCWdvdG8gb3V0Ow0KIAl9DQogDQotCS8qIEdyYWIg ZGV2aWNlIHF1ZXVlICovDQotCXNwaW5fbG9ja19iaCgmZGV2LT5xdWV1ZV9s b2NrKTsNCisJcmN1X3JlYWRfbG9jaygpOw0KKwkvKiBVcGRhdGVzIG9mIHFk aXNjIGFyZSBzZXJpYWxpemVkIGJ5IHF1ZXVlX2xvY2suIA0KKwkgKiBUaGUg c3RydWN0IFFkaXNjIHdoaWNoIGlzIHBvaW50ZWQgdG8gYnkgcWRpc2MgaXMg bm93IGEgDQorCSAqIHJjdSBzdHJ1Y3R1cmUgLSBpdCBtYXkgYmUgYWNjZXNz ZWQgd2l0aG91dCBhY3F1aXJpbmcgDQorCSAqIGEgbG9jayAoYnV0IHRoZSBz dHJ1Y3R1cmUgbWF5IGJlIHN0YWxlLikgVGhlIGZyZWVpbmcgb2YgdGhlDQor CSAqIHFkaXNjIHdpbGwgYmUgZGVmZXJyZWQgdW50aWwgaXQncyBrbm93biB0 aGF0IHRoZXJlIGFyZSBubyANCisJICogbW9yZSByZWZlcmVuY2VzIHRvIGl0 Lg0KKwkgKiANCisJICogSWYgdGhlIHFkaXNjIGhhcyBhbiBlbnF1ZXVlIGZ1 bmN0aW9uLCB3ZSBzdGlsbCBuZWVkIHRvIA0KKwkgKiBob2xkIHRoZSBxdWV1 ZV9sb2NrIGJlZm9yZSBjYWxsaW5nIGl0LCBzaW5jZSBxdWV1ZV9sb2NrDQor CSAqIGFsc28gc2VyaWFsaXplcyBhY2Nlc3MgdG8gdGhlIGRldmljZSBxdWV1 ZS4NCisJICovDQorDQogCXEgPSBkZXYtPnFkaXNjOw0KKwlzbXBfcmVhZF9i YXJyaWVyX2RlcGVuZHMoKTsNCiAJaWYgKHEtPmVucXVldWUpIHsNCisJCS8q IEdyYWIgZGV2aWNlIHF1ZXVlICovDQorCQlzcGluX2xvY2tfYmgoJmRldi0+ cXVldWVfbG9jayk7DQorDQogCQlyYyA9IHEtPmVucXVldWUoc2tiLCBxKTsN CiANCiAJCXFkaXNjX3J1bihkZXYpOw0KIA0KIAkJc3Bpbl91bmxvY2tfYmgo JmRldi0+cXVldWVfbG9jayk7DQorCQlyY3VfcmVhZF91bmxvY2soKTsNCiAJ CXJjID0gcmMgPT0gTkVUX1hNSVRfQllQQVNTID8gTkVUX1hNSVRfU1VDQ0VT UyA6IHJjOw0KIAkJZ290byBvdXQ7DQogCX0NCisJcmN1X3JlYWRfdW5sb2Nr KCk7DQogDQogCS8qIFRoZSBkZXZpY2UgaGFzIG5vIHF1ZXVlLiBDb21tb24g Y2FzZSBmb3Igc29mdHdhcmUgZGV2aWNlczoNCiAJICAgbG9vcGJhY2ssIGFs bCB0aGUgc29ydHMgb2YgdHVubmVscy4uLg0KQEAgLTEzNDcsMTcgKzEzNzks MTIgQEANCiAJICAgRWl0aGVyIHNob3Qgbm9xdWV1ZSBxZGlzYywgaXQgaXMg ZXZlbiBzaW1wbGVyIDgpDQogCSAqLw0KIAlpZiAoZGV2LT5mbGFncyAmIElG Rl9VUCkgew0KKwkJcHJlZW1wdF9kaXNhYmxlKCk7DQogCQlpbnQgY3B1ID0g c21wX3Byb2Nlc3Nvcl9pZCgpOw0KIA0KIAkJaWYgKGRldi0+eG1pdF9sb2Nr X293bmVyICE9IGNwdSkgew0KLQkJCS8qDQotCQkJICogVGhlIHNwaW5fbG9j ayBlZmZlY3Rpdmx5IGRvZXMgYSBwcmVlbXB0IGxvY2ssIGJ1dCANCi0JCQkg KiB3ZSBhcmUgYWJvdXQgdG8gZHJvcCB0aGF0Li4uDQotCQkJICovDQotCQkJ cHJlZW1wdF9kaXNhYmxlKCk7DQotCQkJc3Bpbl91bmxvY2soJmRldi0+cXVl dWVfbG9jayk7DQotCQkJc3Bpbl9sb2NrKCZkZXYtPnhtaXRfbG9jayk7DQot CQkJZGV2LT54bWl0X2xvY2tfb3duZXIgPSBjcHU7DQorDQorCQkJSEFSRF9U WF9MT0NLX0JIKGRldiwgY3B1KTsNCiAJCQlwcmVlbXB0X2VuYWJsZSgpOw0K IA0KIAkJCWlmICghbmV0aWZfcXVldWVfc3RvcHBlZChkZXYpKSB7DQpAQCAt MTM2NiwxOCArMTM5MywxNyBAQA0KIA0KIAkJCQlyYyA9IDA7DQogCQkJCWlm ICghZGV2LT5oYXJkX3N0YXJ0X3htaXQoc2tiLCBkZXYpKSB7DQotCQkJCQlk ZXYtPnhtaXRfbG9ja19vd25lciA9IC0xOw0KLQkJCQkJc3Bpbl91bmxvY2tf YmgoJmRldi0+eG1pdF9sb2NrKTsNCisJCQkJCUhBUkRfVFhfVU5MT0NLX0JI KGRldik7DQogCQkJCQlnb3RvIG91dDsNCiAJCQkJfQ0KIAkJCX0NCi0JCQlk ZXYtPnhtaXRfbG9ja19vd25lciA9IC0xOw0KLQkJCXNwaW5fdW5sb2NrX2Jo KCZkZXYtPnhtaXRfbG9jayk7DQorCQkJSEFSRF9UWF9VTkxPQ0tfQkgoZGV2 KTsNCiAJCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KIAkJCQlwcmludGsoS0VS Tl9DUklUICJWaXJ0dWFsIGRldmljZSAlcyBhc2tzIHRvICINCiAJCQkJICAg ICAgICJxdWV1ZSBwYWNrZXQhXG4iLCBkZXYtPm5hbWUpOw0KIAkJCWdvdG8g b3V0X2VuZXRkb3duOw0KIAkJfSBlbHNlIHsNCisJCQlwcmVlbXB0X2VuYWJs ZSgpOw0KIAkJCS8qIFJlY3Vyc2lvbiBpcyBkZXRlY3RlZCEgSXQgaXMgcG9z c2libGUsDQogCQkJICogdW5mb3J0dW5hdGVseSAqLw0KIAkJCWlmIChuZXRf cmF0ZWxpbWl0KCkpDQpAQCAtMTM4NSw3ICsxNDExLDYgQEANCiAJCQkJICAg ICAgICIlcywgZml4IGl0IHVyZ2VudGx5IVxuIiwgZGV2LT5uYW1lKTsNCiAJ CX0NCiAJfQ0KLQlzcGluX3VubG9ja19iaCgmZGV2LT5xdWV1ZV9sb2NrKTsN CiBvdXRfZW5ldGRvd246DQogCXJjID0gLUVORVRET1dOOw0KIG91dF9rZnJl ZV9za2I6DQotLS0gbGludXgub3JpZy9uZXQvc2NoZWQvc2NoX2dlbmVyaWMu YwkyMDA0LTA2LTA4IDE1OjM2OjUzLjAwMDAwMDAwMCAtMDcwMA0KKysrIGxp bnV4L25ldC9zY2hlZC9zY2hfZ2VuZXJpYy5jCTIwMDQtMDYtMTggMTI6NDg6 NTcuMDAwMDAwMDAwIC0wNzAwDQpAQCAtMzAsNiArMzAsNyBAQA0KICNpbmNs dWRlIDxsaW51eC9za2J1ZmYuaD4NCiAjaW5jbHVkZSA8bGludXgvcnRuZXRs aW5rLmg+DQogI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4NCisjaW5jbHVkZSA8 bGludXgvcmN1cGRhdGUuaD4NCiAjaW5jbHVkZSA8bmV0L3NvY2suaD4NCiAj aW5jbHVkZSA8bmV0L3BrdF9zY2hlZC5oPg0KIA0KQEAgLTM4Nyw2ICszODgs OSBAQA0KIAlzY2gtPmRldiA9IGRldjsNCiAJc2NoLT5zdGF0cy5sb2NrID0g JmRldi0+cXVldWVfbG9jazsNCiAJYXRvbWljX3NldCgmc2NoLT5yZWZjbnQs IDEpOw0KKwkvKiBlbnF1ZXVlIGlzIGFjY2Vzc2VkIGxvY2tsZXNzbHkgLSBt YWtlIHN1cmUgaXQncyB2aXNpYmxlDQorCSAqIGJlZm9yZSB3ZSBzZXQgYSBu ZXRkZXZpY2UncyBxZGlzYyBwb2ludGVyIHRvIHNjaCAqLw0KKwlzbXBfd21i KCk7DQogCWlmICghb3BzLT5pbml0IHx8IG9wcy0+aW5pdChzY2gsIE5VTEwp ID09IDApDQogCQlyZXR1cm4gc2NoOw0KIA0KQEAgLTQwNCwxOCArNDA4LDM2 IEBADQogCQlvcHMtPnJlc2V0KHFkaXNjKTsNCiB9DQogDQorLyogdGhpcyBp cyB0aGUgcmN1IGNhbGxiYWNrIGZ1bmN0aW9uIHRvIGNsZWFuIHVwIGEgcWRp c2Mgd2hlbiB0aGVyZSANCisgKiBhcmUgbm8gZnVydGhlciByZWZlcmVuY2Vz IHRvIGl0ICovDQorDQorc3RhdGljIHZvaWQgX19xZGlzY19kZXN0cm95ICh2 b2lkICogYXJnKSANCit7DQorCXN0cnVjdCBRZGlzYyAgICAqcWRpc2MgPSAo c3RydWN0IFFkaXNjICopIGFyZzsNCisJc3RydWN0IFFkaXNjX29wcyAgKm9w cyA9IHFkaXNjLT5vcHM7DQorDQorI2lmZGVmIENPTkZJR19ORVRfRVNUSU1B VE9SDQorCXFkaXNjX2tpbGxfZXN0aW1hdG9yKCZxZGlzYy0+c3RhdHMpOw0K KyNlbmRpZg0KKwlpZiAob3BzLT5yZXNldCkNCisJCW9wcy0+cmVzZXQocWRp c2MpOw0KKwlpZiAob3BzLT5kZXN0cm95KQ0KKwkJb3BzLT5kZXN0cm95KHFk aXNjKTsNCisJbW9kdWxlX3B1dChvcHMtPm93bmVyKTsNCisNCisJaWYgKCEo cWRpc2MtPmZsYWdzJlRDUV9GX0JVSUxUSU4pKQ0KKwkJa2ZyZWUocWRpc2Mp Ow0KK30NCisNCiAvKiBVbmRlciBkZXYtPnF1ZXVlX2xvY2sgYW5kIEJIISAq Lw0KIA0KIHZvaWQgcWRpc2NfZGVzdHJveShzdHJ1Y3QgUWRpc2MgKnFkaXNj KQ0KIHsNCi0Jc3RydWN0IFFkaXNjX29wcyAqb3BzID0gcWRpc2MtPm9wczsN Ci0Jc3RydWN0IG5ldF9kZXZpY2UgKmRldjsNCisJc3RydWN0IG5ldF9kZXZp Y2UgKmRldiA9IHFkaXNjLT5kZXY7DQogDQogCWlmICghYXRvbWljX2RlY19h bmRfdGVzdCgmcWRpc2MtPnJlZmNudCkpDQogCQlyZXR1cm47DQogDQotCWRl diA9IHFkaXNjLT5kZXY7DQotDQogCWlmIChkZXYpIHsNCiAJCXN0cnVjdCBR ZGlzYyAqcSwgKipxcDsNCiAJCWZvciAocXAgPSAmcWRpc2MtPmRldi0+cWRp c2NfbGlzdDsgKHE9KnFwKSAhPSBOVUxMOyBxcCA9ICZxLT5uZXh0KSB7DQpA QCAtNDI1LDE2ICs0NDcsOSBAQA0KIAkJCX0NCiAJCX0NCiAJfQ0KLSNpZmRl ZiBDT05GSUdfTkVUX0VTVElNQVRPUg0KLQlxZGlzY19raWxsX2VzdGltYXRv cigmcWRpc2MtPnN0YXRzKTsNCi0jZW5kaWYNCi0JaWYgKG9wcy0+cmVzZXQp DQotCQlvcHMtPnJlc2V0KHFkaXNjKTsNCi0JaWYgKG9wcy0+ZGVzdHJveSkN Ci0JCW9wcy0+ZGVzdHJveShxZGlzYyk7DQotCW1vZHVsZV9wdXQob3BzLT5v d25lcik7DQotCWlmICghKHFkaXNjLT5mbGFncyZUQ1FfRl9CVUlMVElOKSkN Ci0JCWtmcmVlKHFkaXNjKTsNCisNCisJY2FsbF9yY3UoJnFkaXNjLT5xX3Jj dSwgX19xZGlzY19kZXN0cm95LCBxZGlzYyk7DQorDQogfQ0KIA0KIA0KLS0t IGxpbnV4Lm9yaWcvbmV0L3NjaGVkL3NjaF9hcGkuYwkyMDA0LTA2LTA4IDE1 OjM2OjUzLjAwMDAwMDAwMCAtMDcwMA0KKysrIGxpbnV4L25ldC9zY2hlZC9z Y2hfYXBpLmMJMjAwNC0wNi0xOCAxMjo1MTo1My4wMDAwMDAwMDAgLTA3MDAN CkBAIC00NTAsNiArNDUwLDkgQEANCiAJaWYgKCF0cnlfbW9kdWxlX2dldChv cHMtPm93bmVyKSkNCiAJCWdvdG8gZXJyX291dDsNCiANCisJLyogZW5xdWV1 ZSBpcyBhY2Nlc3NlZCBsb2NrbGVzc2x5IC0gbWFrZSBzdXJlIGl0J3Mgdmlz aWJsZQ0KKwkgKiBiZWZvcmUgd2Ugc2V0IGEgbmV0ZGV2aWNlJ3MgcWRpc2Mg cG9pbnRlciB0byBzY2ggKi8NCisJc21wX3dtYigpOw0KIAlpZiAoIW9wcy0+ aW5pdCB8fCAoZXJyID0gb3BzLT5pbml0KHNjaCwgdGNhW1RDQV9PUFRJT05T LTFdKSkgPT0gMCkgew0KIAkJd3JpdGVfbG9jaygmcWRpc2NfdHJlZV9sb2Nr KTsNCiAJCXNjaC0+bmV4dCA9IGRldi0+cWRpc2NfbGlzdDsNCg== ---1072017398-1205407494-1087589543=:955203-- From alan@redhat.com Fri Jun 18 13:35:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:35:02 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKYxgi008016 for ; Fri, 18 Jun 2004 13:35: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 i5IKYqe1003031; Fri, 18 Jun 2004 16:34: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 i5IKYq020885; Fri, 18 Jun 2004 16:34:52 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i5IKYY2R001846; Fri, 18 Jun 2004 16:34:34 -0400 Received: (from alan@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id i5IKYYw7001843; Fri, 18 Jun 2004 16:34:34 -0400 Date: Fri, 18 Jun 2004 16:34:34 -0400 From: Alan Cox To: Francois Romieu Cc: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: Re: [PATCH 2.6.7-rc3-mm2 5/5] via-velocity: Rx copybreak Message-ID: <20040618203434.GA826@devserv.devel.redhat.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <20040618221142.A20210@electric-eye.fr.zoreil.com> <20040618221336.B20210@electric-eye.fr.zoreil.com> <20040618221444.C20210@electric-eye.fr.zoreil.com> <20040618221618.D20210@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618221618.D20210@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-archive-position: 6145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@redhat.com Precedence: bulk X-list: netdev Content-Length: 190 Lines: 5 On Fri, Jun 18, 2004 at 10:16:18PM +0200, Francois Romieu wrote: > Some inspiration has been taken from similar r8169 code. All 5 look good to me. Jeff please merge when you send to Linus From davem@redhat.com Fri Jun 18 13:45:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:45:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKjWgi008534 for ; Fri, 18 Jun 2004 13:45:33 -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 i5IKjSe1005621; Fri, 18 Jun 2004 16:45:28 -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 i5IKjS024222; Fri, 18 Jun 2004 16:45:28 -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 i5IKj9kq009035; Fri, 18 Jun 2004 16:45:09 -0400 Date: Fri, 18 Jun 2004 13:44:46 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: lartc@mailman.ds9a.nl, netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) delay scheduler - retry if requeue fails Message-Id: <20040618134446.668b20d4.davem@redhat.com> In-Reply-To: <20040617155559.5aeba553@dell_ss3.pdx.osdl.net> References: <20040617155559.5aeba553@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6146 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: 312 Lines: 10 On Thu, 17 Jun 2004 15:55:59 -0700 Stephen Hemminger wrote: > If delay scheduler decides not to send the packet right away, it requeues > it. If the requeue fails, it should go and look again rather than waking > up prematurely. > > Same patch should apply to both 2.6 and 2.4 Applied. From mcgrof@studorgs.rutgers.edu Fri Jun 18 13:51:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:51:59 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKpugi009464 for ; Fri, 18 Jun 2004 13:51:56 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 101FDF9D4E; Fri, 18 Jun 2004 16:51:56 -0400 (EDT) Date: Fri, 18 Jun 2004 16:51:56 -0400 To: Netdev Subject: [margitsw@t-online.de: Re: 2.6.7] Message-ID: <20040618205156.GM6253@ruslug.rutgers.edu> Mail-Followup-To: Netdev Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 6147 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: 486 Lines: 20 ----- Forwarded message from Margit Schubert-While ----- To: Jeff Garzik From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: 2.6.7 Cc: mcgrof@ruslug.rutgers.edu X-Seen: false X-ID: SOHkCBZQge5mHxVBfzhjSRRrfRiKverfv-Qojo2xc-ehNyTO6wxroP Forward to NETDEV Hi Jeff, 2.6.7-bk1 does not include changes. Why ? Marfit ----- End forwarded message ----- -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From davem@redhat.com Fri Jun 18 13:52:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 13:52:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IKqPgi009544 for ; Fri, 18 Jun 2004 13:52:26 -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 i5IKqLe1007422; Fri, 18 Jun 2004 16:52: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 i5IKqL027004; Fri, 18 Jun 2004 16:52:21 -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 i5IKq2RB013937; Fri, 18 Jun 2004 16:52:03 -0400 Date: Fri, 18 Jun 2004 13:51:39 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [RFT] netif_queue_stopped in TBF scheduler Message-Id: <20040618135139.58d03876.davem@redhat.com> In-Reply-To: <20040617160930.729b35ad@dell_ss3.pdx.osdl.net> References: <58D550446979A646A05649BF9EAF113AA2E995@orsmsx407> <20040617155603.0651081c@dell_ss3.pdx.osdl.net> <20040617160930.729b35ad@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6148 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: 747 Lines: 17 On Thu, 17 Jun 2004 16:09:30 -0700 Stephen Hemminger wrote: > There is a race between the device and scheduler if the scheduler looks > at netif_queue_stopped. What can happen is that the device decides it is ready, > just after the stopped check, and the scheduler decides it is throttled. > > The simple way is to just have the scheduler always dequeue and leave the flow > control up to the driver and the core scheduling loop. CBQ, HFSC, etc. etc. have this same logic too. I agree, the flow control should be handled at the top level by qdisc_restart(), and it does by invoking ->requeue() if the xmit fails at the device level or it cannot obtain the necessary locks. I'm going to make this fix across the board. From davem@redhat.com Fri Jun 18 14:03:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 14:03:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IL3sgi010500 for ; Fri, 18 Jun 2004 14:03:54 -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 i5IL3oe1010440; Fri, 18 Jun 2004 17:03:50 -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 i5IL3o031412; Fri, 18 Jun 2004 17:03: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 i5IL3VFb020979; Fri, 18 Jun 2004 17:03:32 -0400 Date: Fri, 18 Jun 2004 14:03:08 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH] (4/4) add loss option to network delay scheduler Message-Id: <20040618140308.6405efed.davem@redhat.com> In-Reply-To: <20040617155606.558d8eb3@dell_ss3.pdx.osdl.net> References: <20040617155606.558d8eb3@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6149 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: 567 Lines: 14 On Thu, 17 Jun 2004 15:56:06 -0700 Stephen Hemminger wrote: > This enhances the network simulation scheduler to do simple random loss. > > The loss parameter is a simple 32 bit value such that 0 means no loss, and > 0xffffffff is always drop. I have a new version of the tc command which takes > care of conversion from percent to this value. > > Same patch for 2.4 and 2.6 Applied. But the 2.4.x side I had to apply by hand because in 2.4.x's copy if pkt_sched.h there is no empty line before the final #endif and thus patch rejected it. From david@dgreaves.com Fri Jun 18 14:29:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 14:29:30 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ILT1gi011972 for ; Fri, 18 Jun 2004 14:29:02 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id CF2EBE6D34; Fri, 18 Jun 2004 22:28:28 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30769-19; Fri, 18 Jun 2004 22:28:28 +0100 (BST) Received: from oak.dgreaves.com (modem-577.kawau.dialup.pol.co.uk [81.78.146.65]) by mail.ukfsn.org (Postfix) with ESMTP id 862D3E6A86; Fri, 18 Jun 2004 22:28:27 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.82]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BbQwp-0005Ek-Gi; Fri, 18 Jun 2004 22:30:55 +0100 Message-ID: <40D35E95.50104@dgreaves.com> Date: Fri, 18 Jun 2004 22:28:53 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Venkatesan, Ganesh" Cc: Jens Laas , "Glick, Kevin" , netdev@oss.sgi.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> <20040618111124.3a2681b5@dell_ss3.pdx.osdl.net> <40D337FA.1080404@dgreaves.com> <20040618141629.0edd9766@dell_ss3.pdx.osdl.net> In-Reply-To: <20040618141629.0edd9766@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Content-Length: 2191 Lines: 83 OK Thanks for the pointers and time Stephen, much appreciated :) Ganesh and Jens - you said you'd like to keep this on-list so Stephen let's ensure your reply is archived... David Stephen Hemminger wrote: >It will be up to Intel (Genesh et al) to look at this. > > >On Fri, 18 Jun 2004 19:44:10 +0100 >David Greaves wrote: > > > >>Stephen Hemminger wrote: >> >> >> >>>To get to the root of these problems, could you: >>> >>>* Give full lspci -v output for the boards in question. >>> >>> >>> >>> >>ash: >>00:07.0 Ethernet controller: Intel Corp.: Unknown device 1076 >> Subsystem: Intel Corp.: Unknown device 1176 >> Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 11 >> Memory at e3020000 (32-bit, non-prefetchable) [size=128K] >> Memory at e3000000 (32-bit, non-prefetchable) [size=128K] >> I/O ports at b400 [size=64] >> Expansion ROM at [disabled] [size=128K] >> Capabilities: [dc] Power Management version 2 >> Capabilities: [e4] PCI-X non-bridge device. >> Capabilities: [f0] Message Signalled Interrupts: 64bit+ >>Queue=0/0 Enable- >> >> >> > > > >>Jun 18 19:38:18 ash kernel: eth0: may be hung last tx was 2457 ticks >> >> >> > > >This means the code that in the e1000 watchdog is seeing the stuck board. >The driver then calls netif_stop_queue which seems odd. > > > >>Jun 18 19:38:20 ash kernel: eth0: may be hung last tx was 4457 ticks >>Jun 18 19:38:22 ash kernel: eth0: may be hung last tx was 6457 ticks >>Jun 18 19:38:24 ash kernel: eth0: may be hung last tx was 8457 ticks >>Jun 18 19:38:26 ash kernel: NETDEV WATCHDOG: eth0: transmit timed out >>after 5000 j >>iffies >>Jun 18 19:38:26 ash kernel: eth0: transmit timeout from queuing >>Jun 18 19:38:26 ash kernel: eth0: may be hung last tx was 10457 ticks >>Jun 18 19:38:26 ash kernel: eth0: state=0x7 transmit ring size=4096 >>count=256 to_u >>se=66 to_clean=59 >> >> > >The state bits show: > XOFF - stopped (but that was done in e1000_watchdog) > START - board is running > PRESENT - board is present. >That looks okay, but what was the state in the e1000 watchdog?? > > > From kuznet@ms2.inr.ac.ru Fri Jun 18 14:32:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 14:32:18 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ILW1gi012373 for ; Fri, 18 Jun 2004 14:32:02 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id AAA03156; Sat, 19 Jun 2004 00:45:29 +0400 Date: Sat, 19 Jun 2004 00:45:29 +0400 From: Alexey Kuznetsov To: Mark Smith Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [RFC PATCH] Change "local" route table preference from 0 to 3fff, to permit send-to-self policy routing Message-ID: <20040618204529.GA3106@ms2.inr.ac.ru> References: <20040618182505.195d76ba.random@72616e646f6d20323030342d30342d31360a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618182505.195d76ba.random@72616e646f6d20323030342d30342d31360a.nosense.org> User-Agent: Mutt/1.5.6i X-archive-position: 6151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 986 Lines: 23 Hello! > that problem. Something I'll look into further, unless somebody can tell me > that having a host reply its own ARP requests, even when received over a real > interface, isn't possible at all. Sigh, do not you think that making undelatable local rule with preference 0 was an easy decision. This kills most of coolness of policy making yet. :-) Essentially, your patch becomes 100% legal after we kill the places where we ask "Is X.X.X.X our local address?". This thing with arp is one of many places when we have to do this to keep stack relatively coherent. We have several places where we do lookup directly in local table bypassing policy rules, because we just do not have enough information to look in right place. > kernel hacking, if there is a better way to change the "local" route table > preference, I'm all ears. No, really. It is the best. Not made only as fool proof, because adding almost any rule before local one shuts down networking completely. Alexey From romieu@fr.zoreil.com Fri Jun 18 14:46:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 14:47:05 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ILkagi013571 for ; Fri, 18 Jun 2004 14:46:37 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5ILggon022607; Fri, 18 Jun 2004 23:42:42 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5ILgf1J022605; Fri, 18 Jun 2004 23:42:41 +0200 Date: Fri, 18 Jun 2004 23:42:41 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-rc3-mm2 2/5] via-velocity: uniformize use of OWNED_BY_NIC Message-ID: <20040618234241.A21510@electric-eye.fr.zoreil.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <20040618221142.A20210@electric-eye.fr.zoreil.com> <40D3584A.9010009@pobox.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: <40D3584A.9010009@pobox.com>; from jgarzik@pobox.com on Fri, Jun 18, 2004 at 05:02:02PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 6152 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: 607 Lines: 29 Jeff Garzik : > Francois Romieu wrote: [...] > > +static inline void velocity_give_rx_desc(struct rx_desc *rd) > > +{ > > + *(u32 *)&rd->rdesc0 = 0; > > + rd->rdesc0.owner = cpu_to_le32(OWNED_BY_NIC); > > +} > > The patch itself is OK, and I will merge, but I wonder: > > isn't a wmb() needed perhaps? /me scratches head... Ok, everything should be fine with a change in velocity_give_many_rx_descs(): [...] if (vptr->rd_filled < 4) return; unusable = vptr->rd_filled | 0x0003; I'll queue that for the next serie. -- Ueimor From akpm@osdl.org Fri Jun 18 15:09:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 15:09:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IM9Vgi015327 for ; Fri, 18 Jun 2004 15:09:32 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i5IM8Rr06883; Fri, 18 Jun 2004 15:08:27 -0700 Date: Fri, 18 Jun 2004 15:11:17 -0700 From: Andrew Morton To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, jgarzik@pobox.com, gwingerde@home.nl, sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink Message-Id: <20040618151117.2f191d7f.akpm@osdl.org> In-Reply-To: <20040617204644.GB3341@bougret.hpl.hp.com> References: <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> <40D1EC54.8000904@pobox.com> <20040617193154.GE32216@bougret.hpl.hp.com> <40D1F687.6030307@pobox.com> <20040617204644.GB3341@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6153 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: 564 Lines: 12 Coming into this with my lateness exceeded only by my lack of context, I'd say that I share Jean's concern over making incompatible changes to the wireless user<->kernel interface at this time. If we can retain _both_ interfaces in 2.6, remove the old one in 2.7 then maybe that'll be OK. But I do wonder whether this API is the uppermost issue with the wireless drivers. There seem to be a lot of bug reports, and these drivers are *really* complex, and there are lots of out-of-tree drivers. Aren't these the things which we should be devoting cycles to? From romieu@fr.zoreil.com Fri Jun 18 15:10:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 15:10:37 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IMAWgi015512 for ; Fri, 18 Jun 2004 15:10:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5IM7jon023263; Sat, 19 Jun 2004 00:07:45 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5IM7hTU023262; Sat, 19 Jun 2004 00:07:43 +0200 Date: Sat, 19 Jun 2004 00:07:43 +0200 From: Francois Romieu To: Netdev Cc: margitsw@t-online.de, mcgrof@studorgs.rutgers.edu Subject: Re: [margitsw@t-online.de: Re: 2.6.7] Message-ID: <20040619000743.B21510@electric-eye.fr.zoreil.com> References: <20040618205156.GM6253@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040618205156.GM6253@ruslug.rutgers.edu>; from mcgrof@studorgs.rutgers.edu on Fri, Jun 18, 2004 at 04:51:56PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 6154 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: 309 Lines: 9 Luis R. Rodriguez : > ----- Forwarded message from Margit Schubert-While ----- [...] > 2.6.7-bk1 does not include changes. Why ? You may consider subscribing to the bk-commits-head ml. See http://vger.kernel.org/vger-lists.html#bk-commits-head For info: From herbert@gondor.apana.org.au Fri Jun 18 15:22:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 15:22:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IMM1gi016162 for ; Fri, 18 Jun 2004 15:22: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 1BbRjW-0006Df-00; Sat, 19 Jun 2004 08:21:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BbRjS-00062T-00; Sat, 19 Jun 2004 08:21:10 +1000 Date: Sat, 19 Jun 2004 08:21:10 +1000 To: Alexey Kuznetsov Cc: davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-ID: <20040618222110.GA23101@gondor.apana.org.au> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> <20040618202551.GA2733@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618202551.GA2733@ms2.inr.ac.ru> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6155 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: 2393 Lines: 55 On Sat, Jun 19, 2004 at 12:25:51AM +0400, Alexey Kuznetsov wrote: > > Well, I think they are just to be reflected directly in dst->pmtu. > Apparently, incoming ICMPs are to be run not only through raw IP dsts > but also though policy to find matching bundles and make > dst->pmtu = min(new_pmtu, dst->pmtu) on them. That solves the PMTU discovery issue, but it doesn't provide a way for the user to set the MTU using ip r r add 10.10.10.10 mtu 1200 So I think we should still keep the path but set the path to the routing entry for 10.10.10.10 at the top level. Similarly, we can set the path at the segment boundaries (determined by a change in the remote address or perhaps local + remote) to the corresponding routing entries to solve the mid-level PMTU problem. > It is not _within_. Bundles are created per address pair, in your > case 192.168.0.2 -> 10.10.10.10 should be a separate bundle. You're right. I missed that. That's going to be one huge bundle list for the default gateway case :) > Actually, this even does not change things comparing to existing > understanding (not the code though :-(), because after we start > to collect pmtu on SAs, we have to recalculate dst->pmtu too, > it would be kind of expensive to run through bundle and take > minimum of all the dst->pmtu-overhead_at_this_level for > each packet, so we have to precalculate the result and store it > at top level. Absolutely. If it weren't expensive I would've sent in a minimal patch to get xfrm4_tunnel_check_size() to call get_mss() :) What I'm thinking of is to set the dst->path in the way I've described before, and then also store the dst_pmtu inside dst itself. We can then find out when the path's MTU changes due to ICMP messages by comparing dst_pmtu(dst) with dst_metric(dst, RTAX_MTU). If this passes for all dst's in the bundle we keep going, otherwise we start recalculating at the lowest dst. BTW you have to store it at each level and not just the top (well, at least for each tunnel SA) because xfrm4_tunnel_check_size needs this for some reason. In fact by doing this we can get rid of xfrm_get_mss() and replace it with xfrm_state_get_mss() instead. 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 Jun 18 15:50:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 15:50:32 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5IMoUgi017178 for ; Fri, 18 Jun 2004 15:50:30 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id DA18033CE5; Sat, 19 Jun 2004 07:51:28 +0900 (JST) Date: Sat, 19 Jun 2004 07:51:28 +0900 (JST) Message-Id: <20040619.075128.106025605.yoshfuji@linux-ipv6.org> To: kalin@ThinRope.net, andrew@walrond.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: Re: Iptables-1.2.9/10 compile failure with linux 2.6.7 headers From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <40D3361B.5020304@ThinRope.net> References: <40D31EA6.5030207@ThinRope.net> <20040619.021818.04202102.yoshfuji@linux-ipv6.org> <40D3361B.5020304@ThinRope.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: 6156 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: 405 Lines: 13 In article <40D3361B.5020304@ThinRope.net> (at Sat, 19 Jun 2004 03:36:11 +0900), Kalin KOZHUHAROV says: > As far as I understand from this patch, this should be applied to the system headers... Patch is for current linux-2.5 bk tree, not for linux-headers. Please try to patch your kernel and set KERNEL_DIR to /path/to/your/kernel when you compile iptables. Thanks. --yoshfuji From jgarzik@pobox.com Fri Jun 18 15:55:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 15:55: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.12.10/8.12.9) with SMTP id i5IMtBgi017643 for ; Fri, 18 Jun 2004 15:55:12 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbSGL-0000Ci-Hv; Fri, 18 Jun 2004 23:55:09 +0100 Message-ID: <40D372C0.1020509@pobox.com> Date: Fri, 18 Jun 2004 18:54:56 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: jt@hpl.hp.com, jt@bougret.hpl.hp.com, gwingerde@home.nl, sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> <40D1EC54.8000904@pobox.com> <20040617193154.GE32216@bougret.hpl.hp.com> <40D1F687.6030307@pobox.com> <20040617204644.GB3341@bougret.hpl.hp.com> <20040618151117.2f191d7f.akpm@osdl.org> In-Reply-To: <20040618151117.2f191d7f.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6157 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: 2443 Lines: 59 Andrew Morton wrote: > Coming into this with my lateness exceeded only by my lack of context, I'd > say that I share Jean's concern over making incompatible changes to the > wireless user<->kernel interface at this time. If we can retain _both_ > interfaces in 2.6, remove the old one in 2.7 then maybe that'll be OK. Two points: 1) This is about the _driver_ API. The userland interface is a different issue. In Linux the userland ABI is a holy grail that shouldn't be broken without warnings across major kernel versions. We can easily add netlink support (as Jean demonstrated) without 2) I won't break the stable kernel driver API, so you worries here are unfounded. > But I do wonder whether this API is the uppermost issue with the wireless > drivers. The driver API has got to go. Period. Just look at what a sample driver exports: > static const struct iw_handler_def wavelan_handler_def = > { > .num_standard = sizeof(wavelan_handler)/sizeof(iw_handler), > .num_private = sizeof(wavelan_private_handler)/sizeof(iw_handler), > .num_private_args = sizeof(wavelan_private_args)/sizeof(struct iw_priv_args), > .standard = (iw_handler *) wavelan_handler, > .private = (iw_handler *) wavelan_private_handler, > .private_args = (struct iw_priv_args *) wavelan_private_args, > .spy_offset = ((void *) (&((net_local *) NULL)->spy_data) - > (void *) NULL), > }; It flat out doesn't work with object lifetime rules, taking _offsets_ in driver-local structs into more generic code. As for the wireless drivers themselves, they will change as the HostAP stuff gets integrated more closely into the kernel. > There seem to be a lot of bug reports, and these drivers are > *really* complex, and there are lots of out-of-tree drivers. Aren't these > the things which we should be devoting cycles to? The driver API is one of the causes of complexity. Lack of direct integration into the net stack (see http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 for an example direction) another cause of the complexity. As for out of tree drivers, just look at the web page. Most either (a) have binary-only BLOBs associated or (b) duplicate existing drivers N times. Outside the kernel tree there is no unification, but 3-4 drivers for _every_ wireless chipset. Jeff From mcgrof@studorgs.rutgers.edu Fri Jun 18 17:47:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 17:47:36 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5J0lXgi025560 for ; Fri, 18 Jun 2004 17:47:34 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 4F7FAF9D4E; Fri, 18 Jun 2004 20:47:33 -0400 (EDT) Date: Fri, 18 Jun 2004 20:47:33 -0400 To: Netdev Subject: [margitsw@t-online.de: Re: 2.6.7] Message-ID: <20040619004733.GO6253@ruslug.rutgers.edu> Mail-Followup-To: Netdev Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 6158 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 ----- Forwarded message from Margit Schubert-While ----- To: Jeff Garzik From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: 2.6.7 Cc: mcgrof@ruslug.rutgers.edu X-Seen: false X-ID: JJZ8SoZCoeNm0ZKpFt7gnqPVLuUHqcF0KrWHwMtdRUCyEDfz0rbq6Q Forward to NETDEV At 17:00 18.06.2004 -0400, you wrote: >Margit Schubert-While wrote: >>Forward to NETDEV >>Hi Jeff, >>2.6.7-bk1 does not include changes. Why ? > > >Linus only pulled an hour or so ago. Your push was done according to mail : http://marc.theaimsgroup.com/?l=linux-netdev&m=108743421315453&w=2 Why did it miss ? Margit ----- End forwarded message ----- -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From jgarzik@pobox.com Fri Jun 18 20:29:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Jun 2004 20:29:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5J3TRgi001960 for ; Fri, 18 Jun 2004 20:29:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bb2Iw-0005vh-Hm; Thu, 17 Jun 2004 20:12:06 +0100 Message-ID: <40D1ECFA.9090801@pobox.com> Date: Thu, 17 Jun 2004 15:11:54 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Gertjan van Wingerde , sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: Re: [RFC] Wireless extensions rethink References: <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <20040616204248.GA23617@bougret.hpl.hp.com> <40D0BD5B.201@pobox.com> <20040616223316.GA29618@bougret.hpl.hp.com> <40D0D265.3070804@pobox.com> <20040617174717.GA30460@bougret.hpl.hp.com> <40D1E185.2010201@pobox.com> <20040617185605.GA32216@bougret.hpl.hp.com> <40D1EC54.8000904@pobox.com> In-Reply-To: <40D1EC54.8000904@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6159 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 Jeff Garzik wrote: > Yes, but... that's the way the Linux kernel works. Er, I meant to say, that's NOT the way the kernel works. Talk about a Freudian slip :) Jeff From andrew@walrond.org Sat Jun 19 02:51:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 02:51:51 -0700 (PDT) Received: from cenedra.walrond.org (host213-160-108-25.dsl.vispa.com [213.160.108.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5J9plgi015814 for ; Sat, 19 Jun 2004 02:51:48 -0700 Received: from [192.168.0.2] (helo=bob.mobile) by cenedra.walrond.org with esmtp (Exim 4.34) id 1BbcVh-0006qt-5D; Sat, 19 Jun 2004 10:51:41 +0100 From: Andrew Walrond To: YOSHIFUJI Hideaki / =?utf-8?q?=E5=90=89=E8=97=A4=E8=8B=B1=E6=98=8E?= Subject: Re: Iptables-1.2.9/10 compile failure with linux 2.6.7 headers Date: Sat, 19 Jun 2004 10:38:50 +0100 User-Agent: KMail/1.6 Cc: kalin@ThinRope.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org References: <40D313DC.7000202@blue-labs.org> <40D31EA6.5030207@ThinRope.net> <20040619.021818.04202102.yoshfuji@linux-ipv6.org> In-Reply-To: <20040619.021818.04202102.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Message-Id: <200406191038.51118.andrew@walrond.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5J9plgi015814 X-archive-position: 6160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrew@walrond.org Precedence: bulk X-list: netdev On Friday 18 Jun 2004 18:18, YOSHIFUJI Hideaki / 吉藤英明 wrote: > > Please try this. Thanks > I can confirm that iptables-1.2.10 builds fine with your patch applied to linux-2.6.7 Andrew Walrond From vda@port.imtp.ilyichevsk.odessa.ua Sat Jun 19 03:29:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 03:29:44 -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.12.10/8.12.9) with SMTP id i5JASmgi016960 for ; Sat, 19 Jun 2004 03:29:14 -0700 Received: (qmail 9068 invoked by alias); 19 Jun 2004 10:28:29 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 19 Jun 2004 10:28:28 -0000 From: Denis Vlasenko To: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) Subject: Re: [Prism54-devel] GUPD (Grand Unified Prism54 Driver) Open discussion Date: Sat, 19 Jun 2004 13:28:22 +0300 User-Agent: KMail/1.5.4 Cc: Netdev , prism54-devel@prism54.org, Margit Schubert-While References: <5.1.0.14.2.20040615143603.02a40b48@pop.t-online.de> <200406160937.50943.vda@port.imtp.ilyichevsk.odessa.ua> <20040616183058.GR6253@ruslug.rutgers.edu> In-Reply-To: <20040616183058.GR6253@ruslug.rutgers.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200406191328.22189.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 6161 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 On Wednesday 16 June 2004 21:30, Luis R. Rodriguez wrote: > On Wed, Jun 16, 2004 at 09:37:50AM +0300, Denis Vlasenko wrote: > > > * WDS - Umm someone on the list had mentioned they had used WDS > > > successfully and had some patches (?) Are you still alive? Are you > > > still working on this? > > > > No promises, but I'd like to take a look at WDS, > > since I just got another prism54. ... which turned to be not prism54 compatible at all. 8( It's Xterasys something which turned out to be built around TI ACX111 chip. Did Xterasys play "let's change chipset again" game or I was mistaken that they have prism54 based cards? /me downloads yet another 'bleeding edge' Linux driver... -- vda From yoshfuji@linux-ipv6.org Sat Jun 19 09:34:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 09:34:34 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5JGYUgi032507 for ; Sat, 19 Jun 2004 09:34:31 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1D0BE33CE5; Sun, 20 Jun 2004 01:35:30 +0900 (JST) Date: Sun, 20 Jun 2004 01:35:27 +0900 (JST) Message-Id: <20040620.013527.55353972.yoshfuji@linux-ipv6.org> To: andrew@walrond.org, davem@redhat.com Cc: kalin@ThinRope.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: Re: Iptables-1.2.9/10 compile failure with linux 2.6.7 headers From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200406191038.51118.andrew@walrond.org> References: <40D31EA6.5030207@ThinRope.net> <20040619.021818.04202102.yoshfuji@linux-ipv6.org> <200406191038.51118.andrew@walrond.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: 6162 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 <200406191038.51118.andrew@walrond.org> (at Sat, 19 Jun 2004 10:38:50 +0100), Andrew Walrond says: > On Friday 18 Jun 2004 18:18, YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > > Please try this. Thanks > > > > I can confirm that iptables-1.2.10 builds fine with your patch applied to > linux-2.6.7 Thanks. David? --yoshfuji From garzik@havoc.gtf.org Sat Jun 19 18:27:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 18:27:59 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K1Rggi014338 for ; Sat, 19 Jun 2004 18:27:42 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 05C557729 for ; Sat, 19 Jun 2004 18:05:41 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5JM5egk022794 for netdev@oss.sgi.com; Sat, 19 Jun 2004 18:05:40 -0400 Date: Sat, 19 Jun 2004 18:05:40 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x net driver updates Message-ID: <20040619220540.GA22726@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5K1Rggi014338 X-archive-position: 6165 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 This is what I'm submitting right now to Andrew/Linus. Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/e1000/e1000.h | 1 drivers/net/e1000/e1000_hw.c | 35 +++ drivers/net/e1000/e1000_hw.h | 2 drivers/net/e1000/e1000_main.c | 10 drivers/net/eql.c | 4 drivers/net/hamachi.c | 4 drivers/net/hamradio/hdlcdrv.c | 2 drivers/net/pcnet32.c | 71 ++++-- drivers/net/sb1250-mac.c | 4 drivers/net/sgiseeq.c | 145 +++++++------ drivers/net/sk98lin/h/skdrv2nd.h | 3 drivers/net/skfp/cfm.c | 35 --- drivers/net/skfp/drvfbi.c | 181 ++++------------- drivers/net/skfp/ecm.c | 33 +-- drivers/net/skfp/ess.c | 62 ++--- drivers/net/skfp/fplustm.c | 190 +++++------------- drivers/net/skfp/h/cmtdef.h | 322 +++++++++++++----------------- drivers/net/skfp/h/smtstate.h | 6 drivers/net/skfp/hwmtm.c | 221 +++++++++------------ drivers/net/skfp/hwt.c | 27 -- drivers/net/skfp/lnkstat.c | 15 - drivers/net/skfp/pcmplc.c | 164 ++++----------- drivers/net/skfp/pmf.c | 78 ++----- drivers/net/skfp/queue.c | 24 -- drivers/net/skfp/rmt.c | 70 ++---- drivers/net/skfp/skfddi.c | 17 - drivers/net/skfp/smt.c | 407 +++++++++++++-------------------------- drivers/net/skfp/smtdef.c | 31 -- drivers/net/skfp/smtinit.c | 11 - drivers/net/skfp/smtparse.c | 26 -- drivers/net/skfp/smttimer.c | 35 --- drivers/net/skfp/srf.c | 34 +-- drivers/net/smc9194.c | 74 ++++++- drivers/net/sunhme.c | 3 drivers/net/tc35815.c | 2 drivers/net/wireless/airo.c | 40 ++- drivers/net/wireless/orinoco.c | 3 37 files changed, 984 insertions(+), 1408 deletions(-) through these ChangeSets: : o sunhme patch Arjan van de Ven: o sk98lin pci id David S. Miller: o hamachi DMA Don Fry: o pcnet32: cleanup IRQ limitation o pcnet32: recover after rx hang o pcnet32: discard oversize rx packets Herbert Xu: o Re: linux-2.6.7 Equalizer Load-balancer. eql.c. local non-privileged DoS Javier Achirica: o [wireless airo] Clean initialization of Mini-PCI cards even from suspend Jeb J. Cramer: o e1000 management reset fix Ralf Bchle: o hdlcdrv needs to stop queueing o Cosmetic cleanups to sb1250-mac.c o Reformat o Use netdev_priv in sgiseeq Ryan Anderson: o orinoco.c rate limit lost information frame message Stephen Hemminger: o convert sk fddi driver to ANSI C Yoshinori Sato: o H8/300: smc9194 driver From davem@redhat.com Sat Jun 19 18:51:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 18:51:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K1pLgi014840 for ; Sat, 19 Jun 2004 18:51: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 i5JNpke1011384; Sat, 19 Jun 2004 19:51: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 i5JNpk010203; Sat, 19 Jun 2004 19:51:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i5JNpRON005776; Sat, 19 Jun 2004 19:51:27 -0400 Date: Sat, 19 Jun 2004 16:51:45 -0700 (PDT) Message-Id: <20040619.165145.59464986.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ECONET: fix compilation failure From: "David S. Miller" In-Reply-To: <20040620.085010.118083833.yoshfuji@linux-ipv6.org> References: <20040620.080053.38195926.yoshfuji@linux-ipv6.org> <20040619.160451.74729090.davem@redhat.com> <20040620.085010.118083833.yoshfuji@linux-ipv6.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 6166 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 From: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Sun, 20 Jun 2004 08:50:10 +0900 (JST) --- a/net/econet/af_econet.c Sun Jun 20 08:38:31 2004 +++ b/net/econet/af_econet.c Sun Jun 20 08:38:59 2004 Applied, thanks. From mcr@sandelman.ottawa.on.ca Sat Jun 19 18:53:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 18:53:27 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K1rIgi014996 for ; Sat, 19 Jun 2004 18:53:20 -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 i5JJkuP02129 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 19 Jun 2004 15:46:59 -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 i5JAnUH19428 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 19 Jun 2004 06:49:45 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5J3Xc36007887 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Jun 2004 23:33:38 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5J3XZDS007883; Fri, 18 Jun 2004 23:33:35 -0400 To: "David S. Miller" cc: Herbert Xu , kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU In-Reply-To: Message from "David S. Miller" of "Thu, 17 Jun 2004 16:14:03 PDT." <20040617161403.2d0ee598.davem@redhat.com> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> <20040617152921.730892c7.davem@redhat.com> <20040617231241.GB14739@gondor.apana.org.au> <20040617161403.2d0ee598.davem@redhat.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 18 Jun 2004 23:33:34 -0400 Message-ID: <7882.1087616014@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 6167 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David S Miller writes: >> In my case, the ICMP message is not coming from the remote IPsec >> gateway or a router in front of it. It's coming from a host >> behind it. So the original IP header is in the ICMP message, in >> the clear. David> Remote gateway is supposed to encapsulate the ICMP message David> and send it back to the other gateway isn't it? Maybe. Maybe not. The policy may be per-port, or based upon some other more complicated policy. - -- ] "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 iQCVAwUBQNO0DYqHRg3pndX9AQF28QP/bSgt3W2Sp6NOh4qevn/wtTcbjfE+ku0W KRIChkF4Npot65yQKUzkwm1aV6xxcq+jPTIrgM4BASoOtrMNug2nj7EBowTSHImK abY8KrB2JZsCFIQpa8M0vB89gJ41ufq2NaavLsjkwsPLZZX/IYtrnd8Drt4nAT5s MqXS3xwaoxU= =feOK -----END PGP SIGNATURE----- From davem@redhat.com Sat Jun 19 19:11:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 19:11:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K2BUgi015426 for ; Sat, 19 Jun 2004 19:11:30 -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 i5JN5te1002634; Sat, 19 Jun 2004 19:05: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 i5JN5s002361; Sat, 19 Jun 2004 19:05:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i5JN5ZC0028918; Sat, 19 Jun 2004 19:05:36 -0400 Date: Sat, 19 Jun 2004 16:04:51 -0700 (PDT) Message-Id: <20040619.160451.74729090.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ECONET: fix compilation failure From: "David S. Miller" In-Reply-To: <20040620.080053.38195926.yoshfuji@linux-ipv6.org> References: <20040620.080053.38195926.yoshfuji@linux-ipv6.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 6168 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 From: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Sun, 20 Jun 2004 08:00:53 +0900 (JST) Econet (CONFIG_ECONET) does not compile if "AUN over UDP" (CONFIG_ECONET_UDP) is enabled. D: Fix compilation failure when CONFIG_ECONET_UDP is set. Signed-Off-By: Hideaki YOSHIFUJI Andrew Morton already sent me a fix for this, as follows: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/19 11:36:58-07:00 akpm@osdl.org # [NET]: Fix econet build bustage. # # Signed-off-by: Andrew Morton # Signed-off-by: David S. Miller # # net/econet/af_econet.c # 2004/06/19 11:36:43-07:00 akpm@osdl.org +2 -2 # [NET]: Fix econet build bustage. # # Signed-off-by: Andrew Morton # Signed-off-by: David S. Miller # diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c 2004-06-19 16:00:46 -07:00 +++ b/net/econet/af_econet.c 2004-06-19 16:00:46 -07:00 @@ -255,6 +255,8 @@ struct ec_addr addr; int err; unsigned char port, cb; + struct sk_buff *skb = 0; + struct ec_cb *eb = 0; #ifdef CONFIG_ECONET_AUNUDP struct msghdr udpmsg; struct iovec iov[msg->msg_iovlen+1]; @@ -311,8 +313,6 @@ { /* Real hardware Econet. We're not worthy etc. */ #ifdef CONFIG_ECONET_NATIVE - struct ec_cb *eb; - struct sk_buff *skb; unsigned short proto = 0; dev_hold(dev); From yoshfuji@linux-ipv6.org Sat Jun 19 19:17:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 19:17:09 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K2Gugi015650 for ; Sat, 19 Jun 2004 19:16:56 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6F28133CE5; Sun, 20 Jun 2004 08:00:55 +0900 (JST) Date: Sun, 20 Jun 2004 08:00:53 +0900 (JST) Message-Id: <20040620.080053.38195926.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] ECONET: fix compilation failure 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: 6169 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 Hello. Econet (CONFIG_ECONET) does not compile if "AUN over UDP" (CONFIG_ECONET_UDP) is enabled. D: Fix compilation failure when CONFIG_ECONET_UDP is set. Signed-Off-By: Hideaki YOSHIFUJI Thanks. ===== net/econet/af_econet.c 1.38 vs edited ===== --- 1.38/net/econet/af_econet.c 2004-06-16 12:33:01 +09:00 +++ edited/net/econet/af_econet.c 2004-06-20 07:37:22 +09:00 @@ -201,7 +201,7 @@ return 0; } -#ifdef CONFIG_ECONET_NATIVE +#if defined(CONFIG_ECONET_AUNUDP) || defined(CONFIG_ECONET_NATIVE) /* * Queue a transmit result for the user to be told about. */ @@ -228,7 +228,9 @@ if (sock_queue_rcv_skb(sk, skb) < 0) kfree_skb(skb); } +#endif +#ifdef CONFIG_ECONET_NATIVE /* * Called by the Econet hardware driver when a packet transmit * has completed. Tell the user. @@ -255,6 +257,10 @@ struct ec_addr addr; int err; unsigned char port, cb; +#if defined(CONFIG_ECONET_AUNUDP) || defined(CONFIG_ECONET_NATIVE) + struct sk_buff *skb; + struct ec_cb *eb; +#endif #ifdef CONFIG_ECONET_AUNUDP struct msghdr udpmsg; struct iovec iov[msg->msg_iovlen+1]; @@ -311,8 +317,6 @@ { /* Real hardware Econet. We're not worthy etc. */ #ifdef CONFIG_ECONET_NATIVE - struct ec_cb *eb; - struct sk_buff *skb; unsigned short proto = 0; dev_hold(dev); @@ -717,7 +721,7 @@ #include SOCKOPS_WRAP(econet, PF_ECONET); -#ifdef CONFIG_ECONET_AUNUDP +#if defined(CONFIG_ECONET_AUNUDP) || defined(CONFIG_ECONET_NATIVE) /* * Find the listening socket, if any, for the given data. */ @@ -761,7 +765,9 @@ return sock_queue_rcv_skb(sk, skb); } +#endif +#ifdef CONFIG_ECONET_AUNUDP /* * Send an AUN protocol response. */ -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Sat Jun 19 19:18:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 19:18:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K2I8gi015839 for ; Sat, 19 Jun 2004 19:18: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 i5JJpte1031486; Sat, 19 Jun 2004 15:51: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 i5JJpt001487; Sat, 19 Jun 2004 15:51:55 -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 i5JJpZGe008060; Sat, 19 Jun 2004 15:51:35 -0400 Date: Sat, 19 Jun 2004 12:50:53 -0700 From: "David S. Miller" To: Michael Richardson Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: IPsec and Path MTU Message-Id: <20040619125053.6f4a1f85.davem@redhat.com> In-Reply-To: <7882.1087616014@marajade.sandelman.ottawa.on.ca> References: <20040615124334.GA25164@gondor.apana.org.au> <20040616195653.GC29781@ms2.inr.ac.ru> <20040616231317.GA5742@gondor.apana.org.au> <20040617190158.GA10925@ms2.inr.ac.ru> <20040617213832.GC14089@gondor.apana.org.au> <20040617152921.730892c7.davem@redhat.com> <20040617231241.GB14739@gondor.apana.org.au> <20040617161403.2d0ee598.davem@redhat.com> <7882.1087616014@marajade.sandelman.ottawa.on.ca> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6170 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, 18 Jun 2004 23:33:34 -0400 Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "David" == David S Miller writes: > >> In my case, the ICMP message is not coming from the remote IPsec > >> gateway or a router in front of it. It's coming from a host > >> behind it. So the original IP header is in the ICMP message, in > >> the clear. > > David> Remote gateway is supposed to encapsulate the ICMP message > David> and send it back to the other gateway isn't it? > > Maybe. Maybe not. > The policy may be per-port, or based upon some other more complicated > policy. The policy should therefore match the quoted packet in the ICMP message. From davem@redhat.com Sat Jun 19 19:19:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 19:19:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K2I8gk015839 for ; Sat, 19 Jun 2004 19:19:10 -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 i5JJ05e1020872; Sat, 19 Jun 2004 15:00:05 -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 i5JJ05023992; Sat, 19 Jun 2004 15:00:05 -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 i5JIxjEm026075; Sat, 19 Jun 2004 14:59:46 -0400 Date: Sat, 19 Jun 2004 11:59:04 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: andrew@walrond.org, kalin@ThinRope.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: Re: Iptables-1.2.9/10 compile failure with linux 2.6.7 headers Message-Id: <20040619115904.6cbb1736.davem@redhat.com> In-Reply-To: <20040620.013527.55353972.yoshfuji@linux-ipv6.org> References: <40D31EA6.5030207@ThinRope.net> <20040619.021818.04202102.yoshfuji@linux-ipv6.org> <200406191038.51118.andrew@walrond.org> <20040620.013527.55353972.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 i5K2I8gk015839 X-archive-position: 6171 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 Sun, 20 Jun 2004 01:35:27 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <200406191038.51118.andrew@walrond.org> (at Sat, 19 Jun 2004 10:38:50 +0100), Andrew Walrond says: > > > On Friday 18 Jun 2004 18:18, YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > > > > Please try this. Thanks > > > > > > > I can confirm that iptables-1.2.10 builds fine with your patch applied to > > linux-2.6.7 > > Thanks. David? Applied. From jgarzik@pobox.com Sat Jun 19 19:37:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 19:37: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.12.10/8.12.9) with SMTP id i5K2bDgi016262 for ; Sat, 19 Jun 2004 19:37:14 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbnNm-0002qe-NH; Sat, 19 Jun 2004 22:28:14 +0100 Message-ID: <40D4AFE1.6020508@pobox.com> Date: Sat, 19 Jun 2004 17:28:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [8/9][PATCH 2.6] Small fixes and clean-up References: <20040615174956.GA11359@k3.hellgate.ch> In-Reply-To: <20040615174956.GA11359@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6172 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 Roger Luethi wrote: > @@ -678,22 +681,43 @@ > > io_size = 256; > phy_id = 0; > - if (pci_rev < VT6102) { > + quirks = 0; > + name = "Rhine"; > + mname = "unknown"; > + if (pci_rev < VTunknown0) { > quirks = rqRhineI; > io_size = 128; > - name = "VT86C100A Rhine"; > + mname = "VT86C100A"; > } > - else { > + else if (pci_rev >= VT6102) { > quirks = rqWOL | rqForceReset; > if (pci_rev < VT6105) { > name = "Rhine II"; > quirks |= rqStatusWBRace; /* Rhine-II exclusive */ > + if (pci_rev < VT8231) > + mname = "VT6102"; > + else if (pci_rev < VT8233) > + mname = "VT8231"; > + else if (pci_rev < VT8235) > + mname = "VT8233"; > + else if (pci_rev < VT8237) > + mname = "VT8235"; > + else if (pci_rev < VTunknown1) > + mname = "VT8237"; > } > else { > name = "Rhine III"; > phy_id = 1; /* Integrated PHY, phy_id fixed to 1 */ > if (pci_rev >= VT6105_B0) > quirks |= rq6patterns; > + if (pci_rev < VT6105L) > + mname = "VT6105"; > + else if (pci_rev < VT6107) > + mname = "VT6105L"; > + else if (pci_rev < VT6105M) > + mname = "VT6107"; > + else if (pci_rev >= VT6105M) > + mname = "Management Adapter VT6105M"; > } > } > In Linux lists of model names are discouraged. It's not terribly bad in via-rhine, but overall these things wind up getting patches quite often, and become a maintenance annoyance. It's up to you as maintainer, but I would recommend removing the string completely. For dmesg/printk purposes, the user only needs to know they have a 'via-rhine' controller. > - dev = alloc_etherdev(sizeof(*rp)); > - if (dev == NULL) { > + dev = alloc_etherdev(sizeof(struct rhine_private)); > + if (!dev) { > rc = -ENOMEM; > - printk(KERN_ERR "init_ethernet failed for card #%d\n", > - card_idx); > + printk(KERN_ERR "alloc_etherdev failed\n"); this error message change seems like a step backwards... print out pci_name() or _something_ to let the user know which card failed. > goto err_out; > } > SET_MODULE_OWNER(dev); > SET_NETDEV_DEV(dev, &pdev->dev); > > - rc = pci_request_regions(pdev, shortname); > + rc = pci_request_regions(pdev, DRV_NAME); > if (rc) > goto err_out_free_netdev; > > @@ -768,9 +791,8 @@ > rp = netdev_priv(dev); > rp->quirks = quirks; > > + /* Get chip registers into a sane state */ > rhine_power_init(dev); > - > - /* Reset the chip to erase previous misconfiguration. */ > rhine_hw_init(dev, pioaddr); > > for (i = 0; i < 6; i++) > @@ -778,16 +800,11 @@ > > if (!is_valid_ether_addr(dev->dev_addr)) { > rc = -EIO; > - printk(KERN_ERR "Invalid MAC address for card #%d\n", card_idx); > + printk(KERN_ERR "Invalid MAC address\n"); > goto err_out_unmap; ditto From jgarzik@pobox.com Sat Jun 19 21:21:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 21:21:57 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5K4Lkgi020732 for ; Sat, 19 Jun 2004 21:21:47 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bbn0S-0002La-TM; Sat, 19 Jun 2004 22:04:09 +0100 Message-ID: <40D4AA3C.4090606@pobox.com> Date: Sat, 19 Jun 2004 17:03:56 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-rc3-mm2 1/5] via-velocity: PCI ID move References: <20040618221014.A15640@electric-eye.fr.zoreil.com> In-Reply-To: <20040618221014.A15640@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6174 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 patches 1-3 applied to netdev-2.6 (auto-propagated to -mm). Patch 4 was acceptable but patch(1) rejected. Patch 5 didn't either, presumeably due to dependencies on patch 4. From jgarzik@pobox.com Sat Jun 19 21:31:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Jun 2004 21:31: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.12.10/8.12.9) with SMTP id i5K4Vogi021019 for ; Sat, 19 Jun 2004 21:31:51 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bbn1Y-0002MT-JC; Sat, 19 Jun 2004 22:05:16 +0100 Message-ID: <40D4AA7E.3040804@pobox.com> Date: Sat, 19 Jun 2004 17:05:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "Vitaly V. Bursov" , linux-kernel@vger.kernel.org, alan@redhat.com, davem@redhat.com, netdev@oss.sgi.com Subject: Re: linux-2.6.7 Equalizer Load-balancer. eql.c. local non-privileged DoS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6175 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 From romieu@fr.zoreil.com Sun Jun 20 04:06:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 04:07:03 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KB6Vgi031338 for ; Sun, 20 Jun 2004 04:06:32 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5K8pOon018220; Sun, 20 Jun 2004 10:51:24 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5K8pNRj018219; Sun, 20 Jun 2004 10:51:23 +0200 Date: Sun, 20 Jun 2004 10:51:23 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-rc3-mm2 1/5] via-velocity: PCI ID move Message-ID: <20040620105123.A18108@electric-eye.fr.zoreil.com> References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <40D4AA3C.4090606@pobox.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: <40D4AA3C.4090606@pobox.com>; from jgarzik@pobox.com on Sat, Jun 19, 2004 at 05:03:56PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 6176 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 Jeff Garzik : [...] > Patch 4 was acceptable but patch(1) rejected. Patch 5 didn't either, > presumeably due to dependencies on patch 4. I'll rediff once the next -mm is available. -- Ueimor From hch@lst.de Sun Jun 20 04:23:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 04:23:49 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KBNYgi007690 for ; Sun, 20 Jun 2004 04:23:35 -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 i5KBNSQc013724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Jun 2004 13:23:28 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i5KBNSgt013722; Sun, 20 Jun 2004 13:23:28 +0200 Date: Sun, 20 Jun 2004 13:23:28 +0200 From: Christoph Hellwig To: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: [PATCH] more DECLARE_MUTEX() in headers crap Message-ID: <20040620112328.GB13691@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: 6177 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 okay, the gunk we had in arp_tables is in ip6_tables and ip6_tables, too. In fact those three files see to be 80% copy & paste of each other.. --- 1.8/include/linux/netfilter_ipv4/ip_tables.h 2004-06-19 20:55:10 +02:00 +++ edited/include/linux/netfilter_ipv4/ip_tables.h 2004-06-20 10:25:40 +02:00 @@ -284,8 +284,6 @@ struct ipt_entry entrytable[0]; }; -extern struct semaphore ipt_mutex; - /* Standard return verdict, or do jump. */ #define IPT_STANDARD_TARGET "" /* Error verdict. */ @@ -338,7 +336,6 @@ * Main firewall chains definitions and global var's definitions. */ #ifdef __KERNEL__ -static DECLARE_MUTEX(ipt_mutex); #include extern void ipt_init(void) __init; ===== include/linux/netfilter_ipv6/ip6_tables.h 1.7 vs edited ===== --- 1.7/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-19 20:55:10 +02:00 +++ edited/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-20 10:26:32 +02:00 @@ -107,10 +107,6 @@ u_int64_t pcnt, bcnt; /* Packet and byte counters */ }; -#ifdef __KERNEL__ -static DECLARE_MUTEX(ip6t_mutex); -#endif - /* Values for "flag" field in struct ip6t_ip6 (general ip6 structure). */ #define IP6T_F_PROTO 0x01 /* Set if rule cares about upper protocols */ ===== net/ipv4/netfilter/ip_tables.c 1.24 vs edited ===== --- 1.24/net/ipv4/netfilter/ip_tables.c 2004-06-07 05:15:04 +02:00 +++ edited/net/ipv4/netfilter/ip_tables.c 2004-06-20 12:29:17 +02:00 @@ -61,6 +61,8 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) +static DECLARE_MUTEX(ipt_mutex); + /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) #define ASSERT_WRITE_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) ===== net/ipv6/netfilter/ip6_tables.c 1.29 vs edited ===== --- 1.29/net/ipv6/netfilter/ip6_tables.c 2004-06-07 05:15:04 +02:00 +++ edited/net/ipv6/netfilter/ip6_tables.c 2004-06-20 12:29:29 +02:00 @@ -66,6 +66,7 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) +static DECLARE_MUTEX(ip6t_mutex); /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ip6t_mutex) != 0) From jgarzik@pobox.com Sun Jun 20 04:34:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 04:34: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.12.10/8.12.9) with SMTP id i5KBY1gi008152 for ; Sun, 20 Jun 2004 04:34:02 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbnX3-0002vw-QA; Sat, 19 Jun 2004 22:37:49 +0100 Message-ID: <40D4B221.7010108@pobox.com> Date: Sat, 19 Jun 2004 17:37:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [0/3] mc_filter on big-endian arch References: <20040606165322.GA13247@k3.hellgate.ch> In-Reply-To: <20040606165322.GA13247@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6178 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 you would be kind enough to resend the non-via-rhine patches WRT mc_filter? From rl@hellgate.ch Sun Jun 20 04:47:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 04:47:27 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KBlOgi008835 for ; Sun, 20 Jun 2004 04:47:25 -0700 Received: from k3.hellgate.ch (83.76.117.116) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40D19C0700045C73; Sat, 19 Jun 2004 22:18:38 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id D0050619252; Sun, 20 Jun 2004 00:18:37 +0200 (CEST) Date: Sun, 20 Jun 2004 00:18:37 +0200 From: Roger Luethi To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [6/9][PATCH 2.6] Fix Tx engine race for good Message-ID: <20040619221837.GC3313@k3.hellgate.ch> References: <20040615174933.GA11294@k3.hellgate.ch> <40D4AEA4.6050005@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D4AEA4.6050005@pobox.com> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 6179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev On Sat, 19 Jun 2004 17:22:44 -0400, Jeff Garzik wrote: > Roger Luethi wrote: > >+#define RHINE_WAIT_FOR(condition) do { \ > >+ int i=1024; \ > >+ while (!(condition) && --i) \ > >+ ; \ > >+ if (debug > 1 && i < 512) \ > >+ printk(KERN_INFO "%s: %4d cycles used @ %s:%d\n", \ > >+ DRV_NAME, 1024-i, __func__, __LINE__); \ > >+} while(0) > > empty loops need at least a cpu_relax(), if not a true delay to > guarantee the timing you desire. Sure, I can add a cpu_relax(). FWIW, though, this macro is only used for one purpose: Waiting for registers to reach a certain value. IOW: Every evaluation of "condition" causes an I/O operation (inb or readb). > Also, it would be nice to change the name, since there isn't anything > rhine-specific about this macro. Hmm... It relies on DRV_NAME :-). It's trivial to write a more generic version if there's interest. I'm just trying to keep the namespace clean. ... I just checked: drivers/macintosh/via-cuda.c defines a macro WAIT_FOR that does pretty much the same. Does that already make the case for a generic function for everyone to use? Roger From manfred@colorfullife.com Sun Jun 20 05:15:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 05:15:11 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KCF7gi009674 for ; Sun, 20 Jun 2004 05:15:08 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5KCF2Lw028879; Sun, 20 Jun 2004 14:15:04 +0200 Message-ID: <40D57FC3.9040008@colorfullife.com> Date: Sun, 20 Jun 2004 14:14:59 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: [PATCH] cleanup large frame handling for natsemi.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6180 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, The DP83815/6 by default rejects frames longer that 1518 bytes (including crc). This means that a special flag must be set for 8021q - otherwise mtu sized packets are dropped. The current driver enables this flag only if the buffer size is above 1536 bytes - this is wrong. Additionally, the nic writes up to two bytes behind the indicated end of the buffer. This is not documented, thus I've added 64 bytes - just to be safe. The patch also removes RX_OFFSET from the rx buffer allocation: The nic can only receive to 32-bit aligned addresses, it's a left over from a skeleton driver. Jeff, could you apply it? I've stress tested vlan for an hour with tbench and parallel kernel compiles, not obvious problems. -- Manfred From hch@lst.de Sun Jun 20 05:25:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 05:25:21 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KCPDgi010151 for ; Sun, 20 Jun 2004 05:25:13 -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 i5KBSxQc013813 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Jun 2004 13:28:59 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i5KBSxcI013811; Sun, 20 Jun 2004 13:28:59 +0200 Date: Sun, 20 Jun 2004 13:28:59 +0200 From: Christoph Hellwig To: mlindner@syskonnect.de Cc: netdev@oss.sgi.com Subject: [PATCH] convert skge to pci_driver API (2nd try) Message-ID: <20040620112859.GA13794@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: 6181 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 sorry, forgot to Cc netdev on the first try. [WARNING: untested due to lack of hardware] - convert skge to modern pci probing - fix the removal case to call unregister_netdev before shutting down the hardware there's still lots of leaks in the probe path left, but reworking all that code now is far too much risk without beeing able to actually test it. --- 1.38/drivers/net/sk98lin/skge.c 2004-03-29 19:57:20 +02:00 +++ edited/drivers/net/sk98lin/skge.c 2004-06-20 12:07:58 +02:00 @@ -239,7 +239,7 @@ #ifdef CONFIG_PROC_FS static const char SK_Root_Dir_entry[] = "sk98lin"; -static struct proc_dir_entry *pSkRootDir = NULL; +static struct proc_dir_entry *pSkRootDir; extern struct file_operations sk_proc_fops; #endif @@ -255,9 +255,7 @@ #endif /* global variables *********************************************************/ -static const char *BootString = BOOT_STRING; struct SK_NET_DEVICE *SkGeRootDev = NULL; -static int probed __initdata = 0; static SK_BOOL DoPrintInterfaceChange = SK_TRUE; /* local variables **********************************************************/ @@ -269,289 +267,6 @@ static struct proc_dir_entry *pSkRootDir; #endif - - -/***************************************************************************** - * - * skge_probe - find all SK-98xx adapters - * - * Description: - * This function scans the PCI bus for SK-98xx adapters. Resources for - * each adapter are allocated and the adapter is brought into Init 1 - * state. - * - * Returns: - * 0, if everything is ok - * !=0, on error - */ -static int __init skge_probe (void) -{ - int boards_found = 0; - int vendor_flag = SK_FALSE; - SK_AC *pAC; - DEV_NET *pNet = NULL; - struct pci_dev *pdev = NULL; - struct SK_NET_DEVICE *dev = NULL; - SK_BOOL DeviceFound = SK_FALSE; - SK_BOOL BootStringCount = SK_FALSE; - int retval; -#ifdef CONFIG_PROC_FS - struct proc_dir_entry *pProcFile; -#endif - - if (probed) - return -ENODEV; - probed++; - - - while((pdev = pci_find_class(PCI_CLASS_NETWORK_ETHERNET << 8, pdev))) { - - if (pci_enable_device(pdev)) { - continue; - } - dev = NULL; - pNet = NULL; - - /* Don't handle Yukon2 cards at the moment */ - /* 12-feb-2004 ---- mlindner@syskonnect.de */ - if (pdev->vendor == 0x11ab) { - if ( (pdev->device == 0x4360) || (pdev->device == 0x4361) ) - continue; - } - - SK_PCI_ISCOMPLIANT(vendor_flag, pdev); - if (!vendor_flag) - continue; - - /* Configure DMA attributes. */ - if (pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL) && - pci_set_dma_mask(pdev, (u64) 0xffffffff)) - continue; - - - if ((dev = alloc_etherdev(sizeof(DEV_NET))) == NULL) { - printk(KERN_ERR "Unable to allocate etherdev " - "structure!\n"); - break; - } - - pNet = dev->priv; - pNet->pAC = kmalloc(sizeof(SK_AC), GFP_KERNEL); - if (pNet->pAC == NULL){ - free_netdev(dev); - printk(KERN_ERR "Unable to allocate adapter " - "structure!\n"); - break; - } - - /* Print message */ - if (!BootStringCount) { - /* set display flag to TRUE so that */ - /* we only display this string ONCE */ - BootStringCount = SK_TRUE; - printk("%s\n", BootString); - } - - memset(pNet->pAC, 0, sizeof(SK_AC)); - pAC = pNet->pAC; - pAC->PciDev = pdev; - pAC->PciDevId = pdev->device; - pAC->dev[0] = dev; - pAC->dev[1] = dev; - sprintf(pAC->Name, "SysKonnect SK-98xx"); - pAC->CheckQueue = SK_FALSE; - - pNet->Mtu = 1500; - pNet->Up = 0; - dev->irq = pdev->irq; - retval = SkGeInitPCI(pAC); - if (retval) { - printk("SKGE: PCI setup failed: %i\n", retval); - free_netdev(dev); - continue; - } - - SET_MODULE_OWNER(dev); - dev->open = &SkGeOpen; - dev->stop = &SkGeClose; - dev->hard_start_xmit = &SkGeXmit; - dev->get_stats = &SkGeStats; - dev->last_stats = &SkGeStats; - dev->set_multicast_list = &SkGeSetRxMode; - dev->set_mac_address = &SkGeSetMacAddr; - dev->do_ioctl = &SkGeIoctl; - dev->change_mtu = &SkGeChangeMtu; - dev->flags &= ~IFF_RUNNING; - SET_NETDEV_DEV(dev, &pdev->dev); - -#ifdef SK_ZEROCOPY -#ifdef USE_SK_TX_CHECKSUM - - if (pAC->ChipsetType) { - /* Use only if yukon hardware */ - /* SK and ZEROCOPY - fly baby... */ - dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM; - } -#endif -#endif - - pAC->Index = boards_found; - - if (SkGeBoardInit(dev, pAC)) { - free_netdev(dev); - continue; - } - - /* Register net device */ - if (register_netdev(dev)) { - printk(KERN_ERR "SKGE: Could not register device.\n"); - FreeResources(dev); - free_netdev(dev); - continue; - } - - /* Print adapter specific string from vpd */ - ProductStr(pAC); - printk("%s: %s\n", dev->name, pAC->DeviceStr); - - /* Print configuration settings */ - printk(" PrefPort:%c RlmtMode:%s\n", - 'A' + pAC->Rlmt.Net[0].Port[pAC->Rlmt.Net[0].PrefPort]->PortNumber, - (pAC->RlmtMode==0) ? "Check Link State" : - ((pAC->RlmtMode==1) ? "Check Link State" : - ((pAC->RlmtMode==3) ? "Check Local Port" : - ((pAC->RlmtMode==7) ? "Check Segmentation" : - ((pAC->RlmtMode==17) ? "Dual Check Link State" :"Error"))))); - - SkGeYellowLED(pAC, pAC->IoBase, 1); - - - memcpy((caddr_t) &dev->dev_addr, - (caddr_t) &pAC->Addr.Net[0].CurrentMacAddress, 6); - - /* First adapter... Create proc and print message */ -#ifdef CONFIG_PROC_FS - if (!DeviceFound) { - DeviceFound = SK_TRUE; - SK_MEMCPY(&SK_Root_Dir_entry, BootString, - sizeof(SK_Root_Dir_entry) - 1); - - /*Create proc (directory)*/ - if(!pSkRootDir) { - pSkRootDir = proc_mkdir(SK_Root_Dir_entry, proc_net); - if (!pSkRootDir) { - printk(KERN_WARNING "%s: Unable to create /proc/net/%s", - dev->name, SK_Root_Dir_entry); - } else { - pSkRootDir->owner = THIS_MODULE; - } - } - } - - /* Create proc file */ - if (pSkRootDir && - (pProcFile = create_proc_entry(dev->name, S_IRUGO, - pSkRootDir))) { - pProcFile->proc_fops = &sk_proc_fops; - pProcFile->data = dev; - } - -#endif - - pNet->PortNr = 0; - pNet->NetNr = 0; - - boards_found++; - - /* More then one port found */ - if ((pAC->GIni.GIMacsFound == 2 ) && (pAC->RlmtNets == 2)) { - if ((dev = alloc_etherdev(sizeof(DEV_NET))) == 0) { - printk(KERN_ERR "Unable to allocate etherdev " - "structure!\n"); - break; - } - - pAC->dev[1] = dev; - pNet = dev->priv; - pNet->PortNr = 1; - pNet->NetNr = 1; - pNet->pAC = pAC; - pNet->Mtu = 1500; - pNet->Up = 0; - - dev->open = &SkGeOpen; - dev->stop = &SkGeClose; - dev->hard_start_xmit = &SkGeXmit; - dev->get_stats = &SkGeStats; - dev->last_stats = &SkGeStats; - dev->set_multicast_list = &SkGeSetRxMode; - dev->set_mac_address = &SkGeSetMacAddr; - dev->do_ioctl = &SkGeIoctl; - dev->change_mtu = &SkGeChangeMtu; - dev->flags &= ~IFF_RUNNING; - -#ifdef SK_ZEROCOPY -#ifdef USE_SK_TX_CHECKSUM - if (pAC->ChipsetType) { - /* SG and ZEROCOPY - fly baby... */ - dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM; - } -#endif -#endif - - if (register_netdev(dev)) { - printk(KERN_ERR "SKGE: Could not register device.\n"); - free_netdev(dev); - pAC->dev[1] = pAC->dev[0]; - } else { -#ifdef CONFIG_PROC_FS - if (pSkRootDir - && (pProcFile = create_proc_entry(dev->name, - S_IRUGO, pSkRootDir))) { - pProcFile->proc_fops = &sk_proc_fops; - pProcFile->data = dev; - } -#endif - - memcpy((caddr_t) &dev->dev_addr, - (caddr_t) &pAC->Addr.Net[1].CurrentMacAddress, 6); - - printk("%s: %s\n", dev->name, pAC->DeviceStr); - printk(" PrefPort:B RlmtMode:Dual Check Link State\n"); - } - } - - /* Save the hardware revision */ - pAC->HWRevision = (((pAC->GIni.GIPciHwRev >> 4) & 0x0F)*10) + - (pAC->GIni.GIPciHwRev & 0x0F); - - /* Set driver globals */ - pAC->Pnmi.pDriverFileName = DRIVER_FILE_NAME; - pAC->Pnmi.pDriverReleaseDate = DRIVER_REL_DATE; - - SK_MEMSET(&(pAC->PnmiBackup), 0, sizeof(SK_PNMI_STRUCT_DATA)); - SK_MEMCPY(&(pAC->PnmiBackup), &(pAC->PnmiStruct), - sizeof(SK_PNMI_STRUCT_DATA)); - - /* - * This is bollocks, but we need to tell the net-init - * code that it shall go for the next device. - */ -#ifndef MODULE - dev->base_addr = 0; -#endif - } - - /* - * If we're at this point we're going through skge_probe() for - * the first time. Return success (0) if we've initialized 1 - * or more boards. Otherwise, return failure (-ENODEV). - */ - - return boards_found; -} /* skge_probe */ - - /***************************************************************************** * * SkGeInitPCI - Init the PCI resources @@ -666,9 +381,6 @@ MODULE_PARM(ConType, "1-" __MODULE_STRING(SK_MAX_CARD_PARAM) "s"); MODULE_PARM(PrefPort, "1-" __MODULE_STRING(SK_MAX_CARD_PARAM) "s"); MODULE_PARM(RlmtMode, "1-" __MODULE_STRING(SK_MAX_CARD_PARAM) "s"); -/* not used, just there because every driver should have them: */ -MODULE_PARM(options, "1-" __MODULE_STRING(SK_MAX_CARD_PARAM) "i"); -MODULE_PARM(debug, "i"); /* used for interrupt moderation */ MODULE_PARM(IntsPerSec, "1-" __MODULE_STRING(SK_MAX_CARD_PARAM) "i"); MODULE_PARM(Moderation, "1-" __MODULE_STRING(SK_MAX_CARD_PARAM) "s"); @@ -755,123 +467,12 @@ static char *RlmtMode[SK_MAX_CARD_PARAM] = {"", }; #endif -static int debug = 0; /* not used */ -static int options[SK_MAX_CARD_PARAM] = {0, }; /* not used */ - static int IntsPerSec[SK_MAX_CARD_PARAM]; static char *Moderation[SK_MAX_CARD_PARAM]; static char *ModerationMask[SK_MAX_CARD_PARAM]; static char *AutoSizing[SK_MAX_CARD_PARAM]; static char *Stats[SK_MAX_CARD_PARAM]; - -/***************************************************************************** - * - * skge_init_module - module initialization function - * - * Description: - * Very simple, only call skge_probe and return approriate result. - * - * Returns: - * 0, if everything is ok - * !=0, on error - */ -static int __init skge_init_module(void) -{ - int cards; - SkGeRootDev = NULL; - - /* just to avoid warnings ... */ - debug = 0; - options[0] = 0; - - cards = skge_probe(); - if (cards == 0) { - printk("sk98lin: No adapter found.\n"); - } - return cards ? 0 : -ENODEV; -} /* skge_init_module */ - - -/***************************************************************************** - * - * skge_cleanup_module - module unload function - * - * Description: - * Disable adapter if it is still running, free resources, - * free device struct. - * - * Returns: N/A - */ -static void __exit skge_cleanup_module(void) -{ -DEV_NET *pNet; -SK_AC *pAC; -struct SK_NET_DEVICE *next; -unsigned long Flags; -SK_EVPARA EvPara; - - while (SkGeRootDev) { - pNet = (DEV_NET*) SkGeRootDev->priv; - pAC = pNet->pAC; - next = pAC->Next; - - netif_stop_queue(SkGeRootDev); - SkGeYellowLED(pAC, pAC->IoBase, 0); - - if(pAC->BoardLevel == SK_INIT_RUN) { - /* board is still alive */ - spin_lock_irqsave(&pAC->SlowPathLock, Flags); - EvPara.Para32[0] = 0; - EvPara.Para32[1] = -1; - SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); - EvPara.Para32[0] = 1; - EvPara.Para32[1] = -1; - SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); - SkEventDispatcher(pAC, pAC->IoBase); - /* disable interrupts */ - SK_OUT32(pAC->IoBase, B0_IMSK, 0); - SkGeDeInit(pAC, pAC->IoBase); - spin_unlock_irqrestore(&pAC->SlowPathLock, Flags); - pAC->BoardLevel = SK_INIT_DATA; - /* We do NOT check here, if IRQ was pending, of course*/ - } - - if(pAC->BoardLevel == SK_INIT_IO) { - /* board is still alive */ - SkGeDeInit(pAC, pAC->IoBase); - pAC->BoardLevel = SK_INIT_DATA; - } - - if ((pAC->GIni.GIMacsFound == 2) && pAC->RlmtNets == 2){ - unregister_netdev(pAC->dev[1]); - free_netdev(pAC->dev[1]); - } - - FreeResources(SkGeRootDev); - - SkGeRootDev->get_stats = NULL; - /* - * otherwise unregister_netdev calls get_stats with - * invalid IO ... :-( - */ - unregister_netdev(SkGeRootDev); - free_netdev(SkGeRootDev); - kfree(pAC); - SkGeRootDev = next; - } - -#ifdef CONFIG_PROC_FS - /* clear proc-dir */ - remove_proc_entry(pSkRootDir->name, proc_net); -#endif - -} /* skge_cleanup_module */ - -module_init(skge_init_module); -module_exit(skge_cleanup_module); - - /***************************************************************************** * * SkGeBoardInit - do level 0 and 1 initialization @@ -5310,8 +4911,321 @@ #endif -/******************************************************************************* - * - * End of file - * - ******************************************************************************/ +static int __devinit skge_probe_one(struct pci_dev *pdev, + const struct pci_device_id *ent) +{ + SK_AC *pAC; + DEV_NET *pNet = NULL; + struct net_device *dev = NULL; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *pProcFile; +#endif + static int boards_found = 0; + int error = -ENODEV; + + if (pci_enable_device(pdev)) + goto out; + + /* Configure DMA attributes. */ + if (pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL) && + pci_set_dma_mask(pdev, (u64) 0xffffffff)) + goto out_disable_device; + + + if ((dev = alloc_etherdev(sizeof(DEV_NET))) == NULL) { + printk(KERN_ERR "Unable to allocate etherdev " + "structure!\n"); + goto out_disable_device; + } + + pNet = dev->priv; + pNet->pAC = kmalloc(sizeof(SK_AC), GFP_KERNEL); + if (!pNet->pAC) { + printk(KERN_ERR "Unable to allocate adapter " + "structure!\n"); + goto out_free_netdev; + } + + memset(pNet->pAC, 0, sizeof(SK_AC)); + pAC = pNet->pAC; + pAC->PciDev = pdev; + pAC->PciDevId = pdev->device; + pAC->dev[0] = dev; + pAC->dev[1] = dev; + sprintf(pAC->Name, "SysKonnect SK-98xx"); + pAC->CheckQueue = SK_FALSE; + + pNet->Mtu = 1500; + pNet->Up = 0; + dev->irq = pdev->irq; + error = SkGeInitPCI(pAC); + if (error) { + printk("SKGE: PCI setup failed: %i\n", error); + goto out_free_netdev; + } + + SET_MODULE_OWNER(dev); + dev->open = &SkGeOpen; + dev->stop = &SkGeClose; + dev->hard_start_xmit = &SkGeXmit; + dev->get_stats = &SkGeStats; + dev->last_stats = &SkGeStats; + dev->set_multicast_list = &SkGeSetRxMode; + dev->set_mac_address = &SkGeSetMacAddr; + dev->do_ioctl = &SkGeIoctl; + dev->change_mtu = &SkGeChangeMtu; + dev->flags &= ~IFF_RUNNING; + SET_NETDEV_DEV(dev, &pdev->dev); + +#ifdef SK_ZEROCOPY +#ifdef USE_SK_TX_CHECKSUM + if (pAC->ChipsetType) { + /* Use only if yukon hardware */ + /* SK and ZEROCOPY - fly baby... */ + dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM; + } +#endif +#endif + + pAC->Index = boards_found++; + + if (SkGeBoardInit(dev, pAC)) + goto out_free_netdev; + + /* Register net device */ + if (register_netdev(dev)) { + printk(KERN_ERR "SKGE: Could not register device.\n"); + goto out_free_resources; + } + + /* Print adapter specific string from vpd */ + ProductStr(pAC); + printk("%s: %s\n", dev->name, pAC->DeviceStr); + + /* Print configuration settings */ + printk(" PrefPort:%c RlmtMode:%s\n", + 'A' + pAC->Rlmt.Net[0].Port[pAC->Rlmt.Net[0].PrefPort]->PortNumber, + (pAC->RlmtMode==0) ? "Check Link State" : + ((pAC->RlmtMode==1) ? "Check Link State" : + ((pAC->RlmtMode==3) ? "Check Local Port" : + ((pAC->RlmtMode==7) ? "Check Segmentation" : + ((pAC->RlmtMode==17) ? "Dual Check Link State" :"Error"))))); + + SkGeYellowLED(pAC, pAC->IoBase, 1); + + + memcpy(&dev->dev_addr, &pAC->Addr.Net[0].CurrentMacAddress, 6); + +#ifdef CONFIG_PROC_FS + pProcFile = create_proc_entry(dev->name, S_IRUGO, pSkRootDir); + if (pProcFile) { + pProcFile->proc_fops = &sk_proc_fops; + pProcFile->data = dev; + pProcFile->owner = THIS_MODULE; + } +#endif + + pNet->PortNr = 0; + pNet->NetNr = 0; + + boards_found++; + + /* More then one port found */ + if ((pAC->GIni.GIMacsFound == 2 ) && (pAC->RlmtNets == 2)) { + if ((dev = alloc_etherdev(sizeof(DEV_NET))) == 0) { + printk(KERN_ERR "Unable to allocate etherdev " + "structure!\n"); + goto out; + } + + pAC->dev[1] = dev; + pNet = dev->priv; + pNet->PortNr = 1; + pNet->NetNr = 1; + pNet->pAC = pAC; + pNet->Mtu = 1500; + pNet->Up = 0; + + dev->open = &SkGeOpen; + dev->stop = &SkGeClose; + dev->hard_start_xmit = &SkGeXmit; + dev->get_stats = &SkGeStats; + dev->last_stats = &SkGeStats; + dev->set_multicast_list = &SkGeSetRxMode; + dev->set_mac_address = &SkGeSetMacAddr; + dev->do_ioctl = &SkGeIoctl; + dev->change_mtu = &SkGeChangeMtu; + dev->flags &= ~IFF_RUNNING; + +#ifdef SK_ZEROCOPY +#ifdef USE_SK_TX_CHECKSUM + if (pAC->ChipsetType) { + /* SG and ZEROCOPY - fly baby... */ + dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM; + } +#endif +#endif + + if (register_netdev(dev)) { + printk(KERN_ERR "SKGE: Could not register device.\n"); + free_netdev(dev); + pAC->dev[1] = pAC->dev[0]; + } else { +#ifdef CONFIG_PROC_FS + pProcFile = create_proc_entry(dev->name, S_IRUGO, + pSkRootDir); + if (pProcFile) { + pProcFile->proc_fops = &sk_proc_fops; + pProcFile->data = dev; + pProcFile->owner = THIS_MODULE; + } +#endif + + memcpy(&dev->dev_addr, + &pAC->Addr.Net[1].CurrentMacAddress, 6); + + printk("%s: %s\n", dev->name, pAC->DeviceStr); + printk(" PrefPort:B RlmtMode:Dual Check Link State\n"); + } + } + + /* Save the hardware revision */ + pAC->HWRevision = (((pAC->GIni.GIPciHwRev >> 4) & 0x0F)*10) + + (pAC->GIni.GIPciHwRev & 0x0F); + + /* Set driver globals */ + pAC->Pnmi.pDriverFileName = DRIVER_FILE_NAME; + pAC->Pnmi.pDriverReleaseDate = DRIVER_REL_DATE; + + memset(&pAC->PnmiBackup, 0, sizeof(SK_PNMI_STRUCT_DATA)); + memcpy(&pAC->PnmiBackup, &pAC->PnmiStruct, sizeof(SK_PNMI_STRUCT_DATA)); + + pci_set_drvdata(pdev, dev); + return 0; + + out_free_resources: + FreeResources(dev); + out_free_netdev: + free_netdev(dev); + out_disable_device: + pci_disable_device(pdev); + out: + return error; +} + +static void __devexit skge_remove_one(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + DEV_NET *pNet = (DEV_NET *) dev->priv; + SK_AC *pAC = pNet->pAC; + int have_second_mac = 0; + + if ((pAC->GIni.GIMacsFound == 2) && pAC->RlmtNets == 2) + have_second_mac = 1; + + unregister_netdev(dev); + if (have_second_mac) + unregister_netdev(pAC->dev[1]); + + SkGeYellowLED(pAC, pAC->IoBase, 0); + + if (pAC->BoardLevel == SK_INIT_RUN) { + SK_EVPARA EvPara; + unsigned long Flags; + + /* board is still alive */ + spin_lock_irqsave(&pAC->SlowPathLock, Flags); + EvPara.Para32[0] = 0; + EvPara.Para32[1] = -1; + SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); + EvPara.Para32[0] = 1; + EvPara.Para32[1] = -1; + SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); + SkEventDispatcher(pAC, pAC->IoBase); + /* disable interrupts */ + SK_OUT32(pAC->IoBase, B0_IMSK, 0); + SkGeDeInit(pAC, pAC->IoBase); + spin_unlock_irqrestore(&pAC->SlowPathLock, Flags); + pAC->BoardLevel = SK_INIT_DATA; + /* We do NOT check here, if IRQ was pending, of course*/ + } + + if (pAC->BoardLevel == SK_INIT_IO) { + /* board is still alive */ + SkGeDeInit(pAC, pAC->IoBase); + pAC->BoardLevel = SK_INIT_DATA; + } + + FreeResources(dev); + free_netdev(dev); + if (have_second_mac) + free_netdev(pAC->dev[1]); + kfree(pAC); +} + +static struct pci_device_id skge_pci_tbl[] = { + { PCI_VENDOR_ID_3COM, 0x1700, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { PCI_VENDOR_ID_3COM, 0x80eb, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { PCI_VENDOR_ID_SYSKONNECT, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { PCI_VENDOR_ID_SYSKONNECT, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { 0x1186 /* D-Link */, 0x4c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { PCI_VENDOR_ID_MARVELL, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + + /* + * Don't handle Yukon2 cards at the moment (2004-02-12) + * -- mlindner@syskonnect.de + */ +#if 0 + { PCI_VENDOR_ID_MARVELL, 0x4360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { PCI_VENDOR_ID_MARVELL, 0x4361, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, +#endif + { PCI_VENDOR_ID_MARVELL, 0x5005, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { 0x1371 /* CNet */, 0x434e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { 0x1737 /* Linksys */, 0x1032, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { 0x1737 /* Linksys */, 0x1064, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { 0, } +}; + +static struct pci_driver skge_driver = { + .name = "skge", + .id_table = skge_pci_tbl, + .probe = skge_probe_one, + .remove = __devexit_p(skge_remove_one), +}; + +static int __init skge_init(void) +{ + int error; + + memcpy(&SK_Root_Dir_entry, BOOT_STRING, sizeof(SK_Root_Dir_entry) - 1); + +#ifdef CONFIG_PROC_FS + pSkRootDir = proc_mkdir(SK_Root_Dir_entry, proc_net); + if (!pSkRootDir) { + printk(KERN_WARNING "Unable to create /proc/net/%s", + SK_Root_Dir_entry); + return -ENOMEM; + } + pSkRootDir->owner = THIS_MODULE; +#endif + + error = pci_module_init(&skge_driver); + if (error) { +#ifdef CONFIG_PROC_FS + remove_proc_entry(pSkRootDir->name, proc_net); +#endif + } + + return error; +} + +static void __exit skge_exit(void) +{ + pci_unregister_driver(&skge_driver); +#ifdef CONFIG_PROC_FS + remove_proc_entry(pSkRootDir->name, proc_net); +#endif +} + +module_init(skge_init); +module_exit(skge_exit); ===== drivers/net/sk98lin/h/skdrv2nd.h 1.10 vs edited ===== --- 1.10/drivers/net/sk98lin/h/skdrv2nd.h 2004-06-19 02:00:00 +02:00 +++ edited/drivers/net/sk98lin/h/skdrv2nd.h 2004-06-20 10:29:02 +02:00 @@ -53,60 +53,6 @@ #include "h/skrlmt.h" #include "h/skgedrv.h" -#define SK_PCI_ISCOMPLIANT(result, pdev) { \ - result = SK_FALSE; /* default */ \ - /* 3Com (0x10b7) */ \ - if (pdev->vendor == 0x10b7) { \ - /* Gigabit Ethernet Adapter (0x1700) */ \ - if ((pdev->device == 0x1700) || \ - (pdev->device == 0x80eb)) { \ - result = SK_TRUE; \ - } \ - /* SysKonnect (0x1148) */ \ - } else if (pdev->vendor == 0x1148) { \ - /* SK-98xx Gigabit Ethernet Server Adapter (0x4300) */ \ - /* SK-98xx V2.0 Gigabit Ethernet Adapter (0x4320) */ \ - if ((pdev->device == 0x4300) || \ - (pdev->device == 0x4320)) { \ - result = SK_TRUE; \ - } \ - /* D-Link (0x1186) */ \ - } else if (pdev->vendor == 0x1186) { \ - /* Gigabit Ethernet Adapter (0x4c00) */ \ - if ((pdev->device == 0x4c00)) { \ - result = SK_TRUE; \ - } \ - /* Marvell (0x11ab) */ \ - } else if (pdev->vendor == 0x11ab) { \ - /* Gigabit Ethernet Adapter (0x4320) */ \ - /* Gigabit Ethernet Adapter (0x4360) */ \ - /* Gigabit Ethernet Adapter (0x4361) */ \ - /* Belkin (0x5005) */ \ - if ((pdev->device == 0x4320) || \ - (pdev->device == 0x4360) || \ - (pdev->device == 0x4361) || \ - (pdev->device == 0x5005)) { \ - result = SK_TRUE; \ - } \ - /* CNet (0x1371) */ \ - } else if (pdev->vendor == 0x1371) { \ - /* GigaCard Network Adapter (0x434e) */ \ - if ((pdev->device == 0x434e)) { \ - result = SK_TRUE; \ - } \ - /* Linksys (0x1737) */ \ - } else if (pdev->vendor == 0x1737) { \ - /* Gigabit Network Adapter (0x1032) */ \ - /* Gigabit Network Adapter (0x1064) */ \ - if ((pdev->device == 0x1032) || \ - (pdev->device == 0x1064)) { \ - result = SK_TRUE; \ - } \ - } else { \ - result = SK_FALSE; \ - } \ -} - extern SK_MBUF *SkDrvAllocRlmtMbuf(SK_AC*, SK_IOC, unsigned); extern void SkDrvFreeRlmtMbuf(SK_AC*, SK_IOC, SK_MBUF*); From manfred@colorfullife.com Sun Jun 20 05:30:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 05:30:46 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KCUfgi010533 for ; Sun, 20 Jun 2004 05:30:42 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5KCUcLw028971; Sun, 20 Jun 2004 14:30:39 +0200 Message-ID: <40D5836D.4090503@colorfullife.com> Date: Sun, 20 Jun 2004 14:30:37 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jgarzik@pobox.com, netdev@oss.sgi.com Subject: [PATCH] convert natsemi.c to netdev_priv Content-Type: multipart/mixed; boundary="------------010206030700040001010702" X-archive-position: 6182 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 This is a multi-part message in MIME format. --------------010206030700040001010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jeff, the attached promised patch that converts natsemi to netdev_priv() instead of directly dereferencing dev->priv, no other changes. The patch is relative to my previous patch that updates the RxAcceptLong handling. Could you apply it to your tree? Thanks. -- Manfred --------------010206030700040001010702 Content-Type: text/plain; name="patch-natsemi-priv" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-natsemi-priv" --- 2.6/drivers/net/natsemi.c 2004-06-20 14:17:48.713142163 +0200 +++ build-2.6/drivers/net/natsemi.c 2004-06-20 14:17:35.052055243 +0200 @@ -756,7 +756,7 @@ static void move_int_phy(struct net_device *dev, int addr) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int target = 31; /* @@ -847,7 +847,7 @@ dev->base_addr = ioaddr; dev->irq = irq; - np = dev->priv; + np = netdev_priv(dev); np->pci_dev = pdev; pci_set_drvdata(pdev, dev); @@ -1109,7 +1109,7 @@ static int mdio_read(struct net_device *dev, int reg) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The 83815 series has two ports: * - an internal transceiver @@ -1123,7 +1123,7 @@ static void mdio_write(struct net_device *dev, int reg, u16 data) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The 83815 series has an internal transceiver; handle separately */ if (dev->if_port == PORT_TP) @@ -1134,7 +1134,7 @@ static void init_phy_fixup(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int i; u32 cfg; @@ -1246,7 +1246,7 @@ static int switch_port_external(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 cfg; cfg = readl(dev->base_addr + ChipConfig); @@ -1278,7 +1278,7 @@ static int switch_port_internal(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; u32 cfg; u16 bmcr; @@ -1329,7 +1329,7 @@ */ static int find_mii(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int tmp; int i; int did_switch; @@ -1378,7 +1378,7 @@ u32 rfcr; u16 pmatch[3]; u16 sopass[3]; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* * Resetting the chip causes some registers to be lost. @@ -1448,7 +1448,7 @@ static void natsemi_reload_eeprom(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; writel(EepromReload, dev->base_addr + PCIBusCfg); @@ -1469,7 +1469,7 @@ static void natsemi_stop_rxtx(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; writel(RxOff | TxOff, ioaddr + ChipCmd); @@ -1489,7 +1489,7 @@ static int netdev_open(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int i; @@ -1538,7 +1538,7 @@ static void do_cable_magic(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (dev->if_port != PORT_TP) return; @@ -1566,7 +1566,7 @@ * (these values all come from National) */ if (!(data & 0x80) || ((data >= 0xd8) && (data <= 0xff))) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* the bug has been triggered - fix the coefficient */ writew(TSTDAT_FIXED, dev->base_addr + TSTDAT); @@ -1582,7 +1582,7 @@ static void undo_cable_magic(struct net_device *dev) { u16 data; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (dev->if_port != PORT_TP) return; @@ -1600,7 +1600,7 @@ static void check_link(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int duplex; u16 bmsr; @@ -1661,7 +1661,7 @@ static void init_registers(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; init_phy_fixup(dev); @@ -1739,7 +1739,7 @@ static void netdev_timer(unsigned long data) { struct net_device *dev = (struct net_device *)data; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int next_tick = 5*HZ; if (netif_msg_timer(np)) { @@ -1804,7 +1804,7 @@ static void dump_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (netif_msg_pktdata(np)) { int i; @@ -1827,7 +1827,7 @@ static void tx_timeout(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; disable_irq(dev->irq); @@ -1858,7 +1858,7 @@ static int alloc_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); np->rx_ring = pci_alloc_consistent(np->pci_dev, sizeof(struct netdev_desc) * (RX_RING_SIZE+TX_RING_SIZE), &np->ring_dma); @@ -1870,7 +1870,7 @@ static void refill_rx(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* Refill the Rx ring buffers. */ for (; np->cur_rx - np->dirty_rx > 0; np->dirty_rx++) { @@ -1899,7 +1899,7 @@ /* Initialize the Rx and Tx rings, along with various 'dev' bits. */ static void init_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; /* 1) TX ring */ @@ -1942,7 +1942,7 @@ static void drain_tx(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; for (i = 0; i < TX_RING_SIZE; i++) { @@ -1959,7 +1959,7 @@ static void drain_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned int buflen = np->rx_buf_sz; int i; @@ -1980,7 +1980,7 @@ static void free_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); pci_free_consistent(np->pci_dev, sizeof(struct netdev_desc) * (RX_RING_SIZE+TX_RING_SIZE), np->rx_ring, np->ring_dma); @@ -1988,7 +1988,7 @@ static void reinit_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; /* drain TX ring */ @@ -2010,7 +2010,7 @@ static int start_tx(struct sk_buff *skb, struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned entry; /* Note: Ordering is important here, set the field with the @@ -2057,7 +2057,7 @@ static void netdev_tx_done(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); for (; np->cur_tx - np->dirty_tx > 0; np->dirty_tx++) { int entry = np->dirty_tx % TX_RING_SIZE; @@ -2103,7 +2103,7 @@ static irqreturn_t intr_handler(int irq, void *dev_instance, struct pt_regs *rgs) { struct net_device *dev = dev_instance; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int boguscnt = max_interrupt_work; unsigned int handled = 0; @@ -2161,7 +2161,7 @@ for clarity and better register allocation. */ static void netdev_rx(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int entry = np->cur_rx % RX_RING_SIZE; int boguscnt = np->dirty_rx + RX_RING_SIZE - np->cur_rx; s32 desc_status = le32_to_cpu(np->rx_head_desc->cmd_status); @@ -2257,7 +2257,7 @@ static void netdev_error(struct net_device *dev, int intr_status) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; spin_lock(&np->lock); @@ -2312,7 +2312,7 @@ static void __get_stats(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The chip only need report frame silently dropped. */ np->stats.rx_crc_errors += readl(ioaddr + RxCRCErrs); @@ -2321,7 +2321,7 @@ static struct net_device_stats *get_stats(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The chip only need report frame silently dropped. */ spin_lock_irq(&np->lock); @@ -2336,7 +2336,7 @@ static void __set_rx_mode(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u8 mc_filter[64]; /* Multicast hash filter */ u32 rx_mode; @@ -2373,7 +2373,7 @@ static void set_rx_mode(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); spin_lock_irq(&np->lock); if (!np->hands_off) __set_rx_mode(dev); @@ -2382,7 +2382,7 @@ static int netdev_ethtool_ioctl(struct net_device *dev, void __user *useraddr) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 cmd; if (get_user(cmd, (u32 __user *)useraddr)) @@ -2553,7 +2553,7 @@ static int netdev_set_wol(struct net_device *dev, u32 newval) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 data = readl(dev->base_addr + WOLCmd) & ~WakeOptsSummary; /* translate to bitmasks this chip understands */ @@ -2582,7 +2582,7 @@ static int netdev_get_wol(struct net_device *dev, u32 *supported, u32 *cur) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 regval = readl(dev->base_addr + WOLCmd); *supported = (WAKE_PHY | WAKE_UCAST | WAKE_MCAST | WAKE_BCAST @@ -2617,7 +2617,7 @@ static int netdev_set_sopass(struct net_device *dev, u8 *newval) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u16 *sval = (u16 *)newval; u32 addr; @@ -2648,7 +2648,7 @@ static int netdev_get_sopass(struct net_device *dev, u8 *data) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u16 *sval = (u16 *)data; u32 addr; @@ -2676,7 +2676,7 @@ static int netdev_get_ecmd(struct net_device *dev, struct ethtool_cmd *ecmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 tmp; ecmd->port = dev->if_port; @@ -2754,7 +2754,7 @@ static int netdev_set_ecmd(struct net_device *dev, struct ethtool_cmd *ecmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (ecmd->port != PORT_TP && ecmd->port != PORT_MII && ecmd->port != PORT_FIBRE) return -EINVAL; @@ -2896,7 +2896,7 @@ static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct mii_ioctl_data *data = if_mii(rq); - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); switch(cmd) { case SIOCETHTOOL: @@ -2955,7 +2955,7 @@ static void enable_wol_mode(struct net_device *dev, int enable_intr) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (netif_msg_wol(np)) printk(KERN_INFO "%s: remaining active for wake-on-lan\n", @@ -2988,7 +2988,7 @@ static int netdev_close(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (netif_msg_ifdown(np)) printk(KERN_DEBUG @@ -3100,7 +3100,7 @@ static int natsemi_suspend (struct pci_dev *pdev, u32 state) { struct net_device *dev = pci_get_drvdata (pdev); - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; rtnl_lock(); @@ -3147,7 +3147,7 @@ static int natsemi_resume (struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata (pdev); - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); rtnl_lock(); if (netif_device_present(dev)) --------------010206030700040001010702-- From rl@hellgate.ch Sun Jun 20 05:47:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 05:47:27 -0700 (PDT) Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KClOgi011151 for ; Sun, 20 Jun 2004 05:47:25 -0700 Received: from k3.hellgate.ch (83.76.117.116) by mail4.bluewin.ch (Bluewin AG 7.0.028) id 40D19C0700045D1B; Sat, 19 Jun 2004 22:23:20 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 94761619252; Sun, 20 Jun 2004 00:23:19 +0200 (CEST) Date: Sun, 20 Jun 2004 00:23:19 +0200 From: Roger Luethi To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [8/9][PATCH 2.6] Small fixes and clean-up Message-ID: <20040619222319.GE3313@k3.hellgate.ch> References: <20040615174956.GA11359@k3.hellgate.ch> <40D4AFE1.6020508@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D4AFE1.6020508@pobox.com> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 6183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev On Sat, 19 Jun 2004 17:28:01 -0400, Jeff Garzik wrote: > In Linux lists of model names are discouraged. It's not terribly bad in > via-rhine, but overall these things wind up getting patches quite often, > and become a maintenance annoyance. > > It's up to you as maintainer, but I would recommend removing the string > completely. For dmesg/printk purposes, the user only needs to know they > have a 'via-rhine' controller. The reason I put that in is that lspci does not identify those chips correctly (because models differ only by PCI revision, not PCI id) and thus people get confused. But maybe I should rather file patches against pci.ids. Okay, I think I'll remove the model names. > >- dev = alloc_etherdev(sizeof(*rp)); > >- if (dev == NULL) { > >+ dev = alloc_etherdev(sizeof(struct rhine_private)); > >+ if (!dev) { > > rc = -ENOMEM; > >- printk(KERN_ERR "init_ethernet failed for card #%d\n", > >- card_idx); > >+ printk(KERN_ERR "alloc_etherdev failed\n"); > > this error message change seems like a step backwards... print out > pci_name() or _something_ to let the user know which card failed. It is indeed. I plan to clean up all error messages together (there are other issues like where dev->name is defined, what information is useful, should use a bit mask instead of debug level, etc.). Roger From vkondra@mail.ru Sun Jun 20 07:03:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 07:03:29 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KE3Egi013014 for ; Sun, 20 Jun 2004 07:03:15 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id D63F0112910 for ; Sun, 20 Jun 2004 10:18:43 +0400 (MSD) Received: from [82.80.32.242] (port=40088 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1Bbvf3-000F6o-00; Sun, 20 Jun 2004 10:18:39 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: wireless management... kernel or user space? Date: Sun, 20 Jun 2004 09:18:12 +0300 User-Agent: KMail/1.6.2 Cc: Jouni Malinen , James Ketrenos References: <40D20373.3020406@linux.jf.intel.com> <20040619190441.GE7340@jm.kir.nu> In-Reply-To: <20040619190441.GE7340@jm.kir.nu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200406200918.17829.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5KE3Egi013014 X-archive-position: 6184 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 19 June 2004 22:04, Jouni Malinen wrote: > > Does anyone have any thoughts on how much logic should be placed into the > > generic 802.11 frame/management/control handling stack vs. pushing to a > > user space component? > > The ideal location of this logic implementation seems to depend a bit on > what one is doing.. [skip] I would add 2 points: - - we should look carefully for timing requirements. For example, for association req/resp, there is no timing requirement in the standard at all; for auth sequence with WEP, there is maximum timeout between 2-nd and 3-rd frames, but it is not very strong. My point is, if there is flow that require timing under 10-20 ms (or even 50), it should be done in kernel. - - there are lots of meta-information associated with self and wireless peers, related to rate scaling, QoS parameters, authentication details etc. I would say there is such entity, "peers data base". It may reside in either user space, or within the kernel. Logically, management entity and peers data base should be on the same side of kernel/user boundary. Rate scaling, if done on the host, is very time critical and should be done in kernel. This pushes me to the point that it should be in kernel. BTW, .1X flow is pure data. It is not management one, in terms of 802.11. Vladimir. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA1Swpqxdj7mhC6o0RAhH3AKCL5CBpytVRs65jl8HHCI2eSbasNACgo+vZ ta5MHMuyGgvqOtlt6LjiD+s= =ZZIH -----END PGP SIGNATURE----- From jgarzik@pobox.com Sun Jun 20 09:19:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 09:19:28 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KGJQgi018714 for ; Sun, 20 Jun 2004 09:19:26 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbnG8-0002Xh-GQ; Sat, 19 Jun 2004 22:20:20 +0100 Message-ID: <40D4AE06.6060403@pobox.com> Date: Sat, 19 Jun 2004 17:20:06 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [0/9] via-rhine: Major surgery References: <20040615174732.GA10241@k3.hellgate.ch> In-Reply-To: <20040615174732.GA10241@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6185 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 all 9 patches applied to netdev-2.6 (and auto-propagated to Andrew's -mm tree). Will push to Linus after comments are resolved. From garzik@havoc.gtf.org Sun Jun 20 09:30:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 09:30:50 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KGUmgi019149 for ; Sun, 20 Jun 2004 09:30:49 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 30CA77683; Sun, 20 Jun 2004 12:30:42 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5KGUajr017073; Sun, 20 Jun 2004 12:30:36 -0400 Date: Sun, 20 Jun 2004 12:30:36 -0400 From: Jeff Garzik To: Manfred Spraul Cc: netdev@oss.sgi.com Subject: Re: [PATCH] cleanup large frame handling for natsemi.c Message-ID: <20040620163036.GD16038@havoc.gtf.org> References: <40D57FC3.9040008@colorfullife.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D57FC3.9040008@colorfullife.com> User-Agent: Mutt/1.4.1i X-archive-position: 6186 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 On Sun, Jun 20, 2004 at 02:14:59PM +0200, Manfred Spraul wrote: > Jeff, could you apply it? I've stress tested vlan for an hour with > tbench and parallel kernel compiles, not obvious problems. I would if you had actually included a patch ;-) Jeff From manfred@colorfullife.com Sun Jun 20 09:43:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 09:43:17 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KGhAgi019683 for ; Sun, 20 Jun 2004 09:43:13 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5KGh7Lw030604; Sun, 20 Jun 2004 18:43:08 +0200 Message-ID: <40D5BE9B.9040106@colorfullife.com> Date: Sun, 20 Jun 2004 18:43:07 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: Re: [PATCH] cleanup large frame handling for natsemi.c References: <40D57FC3.9040008@colorfullife.com> <20040620163036.GD16038@havoc.gtf.org> In-Reply-To: <20040620163036.GD16038@havoc.gtf.org> Content-Type: multipart/mixed; boundary="------------030406000600000305080208" X-archive-position: 6187 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 This is a multi-part message in MIME format. --------------030406000600000305080208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff Garzik wrote: >On Sun, Jun 20, 2004 at 02:14:59PM +0200, Manfred Spraul wrote: > > >>Jeff, could you apply it? I've stress tested vlan for an hour with >>tbench and parallel kernel compiles, not obvious problems. >> >> > >I would if you had actually included a patch ;-) > > > Ups, sorry. Here's the patch. -- Manfred --------------030406000600000305080208 Content-Type: text/plain; name="patch-natsemi-long" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-natsemi-long" --- 2.6/drivers/net/natsemi.c 2004-06-20 11:24:02.959200463 +0200 +++ build-2.6/drivers/net/natsemi.c 2004-06-20 12:11:31.170607816 +0200 @@ -236,7 +236,14 @@ #define NATSEMI_REGS_SIZE (NATSEMI_NREGS * sizeof(u32)) #define NATSEMI_EEPROM_SIZE 24 /* 12 16-bit values */ -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */ +/* Buffer sizes: + * The nic writes 32-bit values, even if the upper bytes of + * a 32-bit value are beyond the end of the buffer. + */ +#define NATSEMI_HEADERS 22 /* 2*mac,type,vlan,crc */ +#define NATSEMI_PADDING 64 /* 2 bytes should be sufficient */ +#define NATSEMI_LONGPKT 1518 /* limit for long packets */ +#define NATSEMI_RX_LIMIT 2046 /* maximum supported by hardware */ /* These identify the driver base version and may not be removed. */ static char version[] __devinitdata = @@ -1688,7 +1695,7 @@ */ np->rx_config = RxMxdma_256 | 0x20; /* if receive ring now has bigger buffers than normal, enable jumbo */ - if (np->rx_buf_sz > PKT_BUF_SZ) + if (np->rx_buf_sz > NATSEMI_LONGPKT) np->rx_config |= RxAcceptLong; writel(np->rx_config, ioaddr + RxConfig); @@ -1870,7 +1877,7 @@ struct sk_buff *skb; int entry = np->dirty_rx % RX_RING_SIZE; if (np->rx_skbuff[entry] == NULL) { - unsigned int buflen = np->rx_buf_sz + RX_OFFSET; + unsigned int buflen = np->rx_buf_sz+NATSEMI_PADDING; skb = dev_alloc_skb(buflen); np->rx_skbuff[entry] = skb; if (skb == NULL) @@ -1909,9 +1916,13 @@ np->dirty_rx = 0; np->cur_rx = RX_RING_SIZE; np->oom = 0; - np->rx_buf_sz = PKT_BUF_SZ; - if (dev->mtu > ETH_DATA_LEN) - np->rx_buf_sz += dev->mtu - ETH_DATA_LEN; + if (dev->mtu <= ETH_DATA_LEN) + np->rx_buf_sz = ETH_DATA_LEN + NATSEMI_HEADERS; + else + np->rx_buf_sz = dev->mtu + NATSEMI_HEADERS; + if (np->rx_buf_sz > NATSEMI_RX_LIMIT) + np->rx_buf_sz = NATSEMI_RX_LIMIT; + np->rx_head_desc = &np->rx_ring[0]; /* Please be carefull before changing this loop - at least gcc-2.95.1 @@ -1949,7 +1960,7 @@ static void drain_ring(struct net_device *dev) { struct netdev_private *np = dev->priv; - unsigned int buflen = np->rx_buf_sz + RX_OFFSET; + unsigned int buflen = np->rx_buf_sz; int i; /* Free all the skbuffs in the Rx queue. */ @@ -2154,7 +2165,7 @@ int entry = np->cur_rx % RX_RING_SIZE; int boguscnt = np->dirty_rx + RX_RING_SIZE - np->cur_rx; s32 desc_status = le32_to_cpu(np->rx_head_desc->cmd_status); - unsigned int buflen = np->rx_buf_sz + RX_OFFSET; + unsigned int buflen = np->rx_buf_sz; /* If the driver owns the next entry it's a new packet. Send it up. */ while (desc_status < 0) { /* e.g. & DescOwn */ @@ -2881,6 +2892,7 @@ } return 0; } + static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct mii_ioctl_data *data = if_mii(rq); --------------030406000600000305080208-- From jgarzik@pobox.com Sun Jun 20 09:59:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 09:59:43 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KGxcgi020161 for ; Sun, 20 Jun 2004 09:59:41 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbnIe-0002ZW-OT; Sat, 19 Jun 2004 22:22:56 +0100 Message-ID: <40D4AEA4.6050005@pobox.com> Date: Sat, 19 Jun 2004 17:22:44 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [6/9][PATCH 2.6] Fix Tx engine race for good References: <20040615174933.GA11294@k3.hellgate.ch> In-Reply-To: <20040615174933.GA11294@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6188 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 Roger Luethi wrote: > +#define RHINE_WAIT_FOR(condition) do { \ > + int i=1024; \ > + while (!(condition) && --i) \ > + ; \ > + if (debug > 1 && i < 512) \ > + printk(KERN_INFO "%s: %4d cycles used @ %s:%d\n", \ > + DRV_NAME, 1024-i, __func__, __LINE__); \ > +} while(0) empty loops need at least a cpu_relax(), if not a true delay to guarantee the timing you desire. Also, it would be nice to change the name, since there isn't anything rhine-specific about this macro. Jeff From jgarzik@pobox.com Sun Jun 20 09:59:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 09:59:44 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KGxggi020169 for ; Sun, 20 Jun 2004 09:59:43 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bbn6n-0002PI-BO; Sat, 19 Jun 2004 22:10:41 +0100 Message-ID: <40D4ABC5.7040203@pobox.com> Date: Sat, 19 Jun 2004 17:10:29 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeb Cramer CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/1 2.4] e1000 management reset fix References: <1087360890.12233.11.camel@mini> In-Reply-To: <1087360890.12233.11.camel@mini> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6189 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 From garzik@havoc.gtf.org Sun Jun 20 12:15:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 12:15:24 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KJFCgi023127 for ; Sun, 20 Jun 2004 12:15:13 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 7A386767A; Sun, 20 Jun 2004 14:38:55 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5KIct9h026518; Sun, 20 Jun 2004 14:38:55 -0400 Date: Sun, 20 Jun 2004 14:38:55 -0400 From: Jeff Garzik To: Manfred Spraul Cc: netdev@oss.sgi.com Subject: Re: [PATCH] cleanup large frame handling for natsemi.c Message-ID: <20040620183855.GA26392@havoc.gtf.org> References: <40D57FC3.9040008@colorfullife.com> <20040620163036.GD16038@havoc.gtf.org> <40D5BE9B.9040106@colorfullife.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D5BE9B.9040106@colorfullife.com> User-Agent: Mutt/1.4.1i X-archive-position: 6190 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 On Sun, Jun 20, 2004 at 06:43:07PM +0200, Manfred Spraul wrote: > @@ -1909,9 +1916,13 @@ > np->dirty_rx = 0; > np->cur_rx = RX_RING_SIZE; > np->oom = 0; > - np->rx_buf_sz = PKT_BUF_SZ; > - if (dev->mtu > ETH_DATA_LEN) > - np->rx_buf_sz += dev->mtu - ETH_DATA_LEN; > + if (dev->mtu <= ETH_DATA_LEN) > + np->rx_buf_sz = ETH_DATA_LEN + NATSEMI_HEADERS; > + else > + np->rx_buf_sz = dev->mtu + NATSEMI_HEADERS; > + if (np->rx_buf_sz > NATSEMI_RX_LIMIT) > + np->rx_buf_sz = NATSEMI_RX_LIMIT; > + Double NAK: 1) Use PKT_BUF_SZ, don't alloc smaller than that. 2) The final check should not be needed. The code should guarantee that np->rx_buf_sz never exceeds NATSEMI_RX_LIMIT. Jeff From manfred@colorfullife.com Sun Jun 20 12:31:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 12:31:53 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5KJVRgi026755 for ; Sun, 20 Jun 2004 12:31:48 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5KJVNLw032162; Sun, 20 Jun 2004 21:31:25 +0200 Message-ID: <40D5E60A.10007@colorfullife.com> Date: Sun, 20 Jun 2004 21:31:22 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: Re: [PATCH] cleanup large frame handling for natsemi.c References: <40D57FC3.9040008@colorfullife.com> <20040620163036.GD16038@havoc.gtf.org> <40D5BE9B.9040106@colorfullife.com> <20040620183855.GA26392@havoc.gtf.org> In-Reply-To: <20040620183855.GA26392@havoc.gtf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6191 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 Jeff Garzik wrote: >On Sun, Jun 20, 2004 at 06:43:07PM +0200, Manfred Spraul wrote: > > >>@@ -1909,9 +1916,13 @@ >> np->dirty_rx = 0; >> np->cur_rx = RX_RING_SIZE; >> np->oom = 0; >>- np->rx_buf_sz = PKT_BUF_SZ; >>- if (dev->mtu > ETH_DATA_LEN) >>- np->rx_buf_sz += dev->mtu - ETH_DATA_LEN; >>+ if (dev->mtu <= ETH_DATA_LEN) >>+ np->rx_buf_sz = ETH_DATA_LEN + NATSEMI_HEADERS; >>+ else >>+ np->rx_buf_sz = dev->mtu + NATSEMI_HEADERS; >>+ if (np->rx_buf_sz > NATSEMI_RX_LIMIT) >>+ np->rx_buf_sz = NATSEMI_RX_LIMIT; >>+ >> >> > >Double NAK: > >1) Use PKT_BUF_SZ, don't alloc smaller than that. > > > The alloc size is never smaller than PKT_BUF_SZ: ETH_DATA_LEN+NATSEMI_HEADERS+NATSEMI_PADDING is 1586 bytes [still smaller than the 1620 byte skb kmalloc cache] >2) The final check should not be needed. The code should guarantee that >np->rx_buf_sz never exceeds NATSEMI_RX_LIMIT. > > > You mean: implement a change_mtu callback and reject mtu values above 2020 byte? -- Manfred > Jeff > > > > From davem@redhat.com Sun Jun 20 17:40:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 17:40:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5L0e4gi004465 for ; Sun, 20 Jun 2004 17:40:05 -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 i5L0e2e1024811; Sun, 20 Jun 2004 20:40: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 i5L0e1028898; Sun, 20 Jun 2004 20:40:01 -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 i5L0dfIa008869; Sun, 20 Jun 2004 20:39:41 -0400 Date: Sun, 20 Jun 2004 17:39:56 -0700 From: "David S. Miller" To: Arthur Kepner Cc: ak@suse.de, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] lockless loopback patch for 2.6 (version 2) Message-Id: <20040620173956.77a2340e.davem@redhat.com> In-Reply-To: References: <20040614182331.GA11862@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: 6192 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, 18 Jun 2004 13:12:23 -0700 Arthur Kepner wrote: > A patch with these changes is attached. This looks fine to me. I'm going to add this to my tree and push upstream. Thanks Arthur. From jgarzik@pobox.com Sun Jun 20 18:19:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 18:19: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.12.10/8.12.9) with SMTP id i5L1JLgi005763 for ; Sun, 20 Jun 2004 18:19:21 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bbn9O-0002QC-Bi; Sat, 19 Jun 2004 22:13:22 +0100 Message-ID: <40D4AC66.1000000@pobox.com> Date: Sat, 19 Jun 2004 17:13:10 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 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.6.7-rc3-bk6] pcnet32: discard oversize rx packets References: <200406151852.i5FIqOh20749@localhost.localdomain> In-Reply-To: <200406151852.i5FIqOh20749@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6194 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 all 3 patches to 2.6.x From jgarzik@pobox.com Sun Jun 20 18:19:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 18:19:24 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5L1JIgi005758 for ; Sun, 20 Jun 2004 18:19:19 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbnKO-0002cd-TO; Sat, 19 Jun 2004 22:24:45 +0100 Message-ID: <40D4AF10.50801@pobox.com> Date: Sat, 19 Jun 2004 17:24:32 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [7/9][PATCH 2.6] Media mode rewrite References: <20040615174942.GA11319@k3.hellgate.ch> In-Reply-To: <20040615174942.GA11319@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6193 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 Roger Luethi wrote: > Remove rhine_check_duplex, rhine_timer and related data structures > > Add rhine_check_media: wrapper for generic mii_check_media, sets duplex > bit in MAC > > Add rhine_enable_linkmon, rhine_disable_linkmon to enable hardware link > status monitoring > > Update mdio_read, mdio_write accordingly > > Remove get_intr_status check in rhine_start_tx because we are not racing > anymore > > Signed-off-by: Roger Luethi > > --- orig/drivers/net/via-rhine.c > +++ mod/drivers/net/via-rhine.c > @@ -485,7 +485,6 @@ > > struct pci_dev *pdev; > struct net_device_stats stats; > - struct timer_list timer; /* Media monitoring timer. */ > spinlock_t lock; > > /* Frequently used values: keep some adjacent for cache effect. */ > @@ -498,16 +497,12 @@ > /* These values are keep track of the transceiver/media in use. */ > u8 tx_thresh, rx_thresh; > > - /* MII transceiver section. */ > - u16 mii_status; /* last read MII status */ > struct mii_if_info mii_if; > }; > > static int mdio_read(struct net_device *dev, int phy_id, int location); > static void mdio_write(struct net_device *dev, int phy_id, int location, int value); > static int rhine_open(struct net_device *dev); > -static void rhine_check_duplex(struct net_device *dev); > -static void rhine_timer(unsigned long data); > static void rhine_tx_timeout(struct net_device *dev); > static int rhine_start_tx(struct sk_buff *skb, struct net_device *dev); > static irqreturn_t rhine_interrupt(int irq, void *dev_instance, struct pt_regs *regs); > @@ -1032,6 +1027,21 @@ > } > } > > +static void rhine_check_media(struct net_device *dev, unsigned int init_media) > +{ > + struct rhine_private *rp = netdev_priv(dev); > + long ioaddr = dev->base_addr; > + > + mii_check_media(&rp->mii_if, debug, init_media); > + > + if (rp->mii_if.full_duplex) > + writeb(readb(ioaddr + ChipCmd1) | Cmd1FDuplex, > + ioaddr + ChipCmd1); > + else > + writeb(readb(ioaddr + ChipCmd1) & ~Cmd1FDuplex, > + ioaddr + ChipCmd1); > +} > + > static void init_registers(struct net_device *dev) > { > struct rhine_private *rp = netdev_priv(dev); > @@ -1047,7 +1057,6 @@ > writeb(0x20, ioaddr + TxConfig); > rp->tx_thresh = 0x20; > rp->rx_thresh = 0x60; /* Written in rhine_set_rx_mode(). */ > - rp->mii_if.full_duplex = 0; > > writel(rp->rx_ring_dma, ioaddr + RxRingPtr); > writel(rp->tx_ring_dma, ioaddr + TxRingPtr); > @@ -1063,14 +1072,42 @@ > > writew(CmdStart|CmdTxOn|CmdRxOn|(Cmd1NoTxPoll << 8), > ioaddr + ChipCmd); > - if (rp->mii_if.force_media) > - writeb(readb(ioaddr + ChipCmd1) | Cmd1FDuplex, > - ioaddr + ChipCmd1); > - else > - writeb(readb(ioaddr + ChipCmd1) & ~Cmd1FDuplex, > - ioaddr + ChipCmd1); > + rhine_check_media(dev, 1); > +} > + > +/* Enable MII link status auto-polling (required for IntrLinkChange) */ > +static void rhine_enable_linkmon(long ioaddr) > +{ > + writeb(0, ioaddr + MIICmd); > + writeb(MII_BMSR, ioaddr + MIIRegAddr); > + writeb(0x80, ioaddr + MIICmd); > > - rhine_check_duplex(dev); > + RHINE_WAIT_FOR((readb(ioaddr + MIIRegAddr) & 0x20)); > + > + writeb(MII_BMSR | 0x40, ioaddr + MIIRegAddr); > +} > + > +/* Disable MII link status auto-polling (required for MDIO access) */ > +static void rhine_disable_linkmon(long ioaddr, u32 quirks) > +{ > + writeb(0, ioaddr + MIICmd); > + > + if (quirks & rqRhineI) { > + writeb(0x01, ioaddr + MIIRegAddr); // MII_BMSR > + > + /* Can be called from ISR. Evil. */ > + mdelay(1); Net drivers are slowly moving towards schedule_work()/queue_work() for doing "slow path" stuff like chip reset or MII phy stuff. Jeff From jgarzik@pobox.com Sun Jun 20 18:29:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Jun 2004 18:29:37 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5L1TSgi006823 for ; Sun, 20 Jun 2004 18:29:29 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bbn49-0002Nk-Mk; Sat, 19 Jun 2004 22:07:57 +0100 Message-ID: <40D4AB20.7000909@pobox.com> Date: Sat, 19 Jun 2004 17:07:44 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] convert sk fddi driver to ANSI C References: <20040617145327.3249f4dc@dell_ss3.pdx.osdl.net> In-Reply-To: <20040617145327.3249f4dc@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6195 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 From zach@abecedaher.cz Mon Jun 21 02:02:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 02:02:34 -0700 (PDT) Received: from oss.sgi.com (poto2.cesnet.cz [195.113.142.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5L92Vgi026720 for ; Mon, 21 Jun 2004 02:02:31 -0700 Message-ID: From: Vladimir Smotlacha To: Subject: Check this out kid!!! Date: po, 21 VI 2004 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16328_0163464.6782783531618" X-Priority: 3 X-archive-position: 6196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zach@abecedaher.cz Precedence: bulk X-list: netdev Microsoft Outlook Express 5.00.2314.1300 ------=_Part_16328_0163464.6782783531618 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Send me back bro, when you`ll be done...(if you know what i mean...) See ya, Vladimir Smotlacha ------=_Part_16328_0163464.6782783531618 Content-Type: application/octet-stream; name="jennifer the wild girl xxx07.jpg.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="jennifer the wild girl xxx07.jpg.pif" TVqQAAMAAAAEAAAAUEUAAEwBAgBGdWFjdgAAAAAAAADgAA8BCwEAAAAuAAAAOgAAAAAAAPu+AAAA EAAADAAAAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAwAAAAAIAAAAAAAACAAAAAAAQAAAQ AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAADAvwAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAAAAACAAAAAEAAAAAAAAAAAAAAA AAAAAAAAAAAAAADgAADgAAAAAHRhAAAAMAAAAJAAAPQvAAAAAgAAAAAAAAAAAAAAAAAA4AAAwEtF Uk5FTDMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAtr9AAKq/QACsv0AAmAFAAAAQQAAAkEAAAVBAAAAAAAA8QkAAAQAAAOi/QAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABq ByBoPXNADq1tC/KnAui3Kg4BxgVCULEiLm9VEwEiKyLqZccLPbcIAw+FYAQYDLgBF+gVYwgKg/jY D4RNwifpVx8AZscFE6M+gb6FsQ+W4FgABIk1YdwP6A8Dm60Fc6nTV4ofJSo9OAh0PLm4KLswDFFT v8ntvqAgrDzANgOq6/iLevPthRZ1+mgDGuioKQNWW1lDigM7J/mZ4s7EsJovQQ4OHgW/rwo+bSkI ogoKgD0WhnQSv/XEJq4JCv4wgevPaFDDmyXYndHSgSQEAaqXBpIrHzOgDxW/HTNqUNgsI75gYINA ZolGAvJeb3ETqj3gY3QF+1MFH1boAythxseL+QzPh1ovb8cGAgxmBO/NCLjzZA4MImpETxQC6On4 wv90laMroyUMn2oQVtqz3zEK/zUQPjehGVaKC1BYXCaudkgOYLDpRP/QAg7IARE2dSr7FcAiiBP8 KMQLjBgFcu884EXGo75EY6ZyOFFW1ONJRyoUi97lhV5TBNMwKjB1A1sr63DWlF7S+Fau00QWXqTU NEBQAjHN5ikmFxgFWALrKuu9URtowfUiNOTfIZuAgalVe0ITyxMiDqwkXln4gXX7SYP5NGlapNVh Swu+91KkUEbJMFMB6FHCP9kDUtYTr+xUIX4qiyd1kI9onDs0s/EgowRsDUQnwKDcUCeTfQV8oyFE jr+CyzAqctiTJwiHBz8kRpjMbkvdjVT6bUhMlZ/Mjo2LUBUbg4B0GqYn/0wjIYREletTvw0QziZD OzfDF0rFGDQZRusS9rgoQpij4ViaqoZIxDv82ModaBMoElAaRRCrDTt+2EQOpsAUAXUH+5g45MMW vgVZNSwCNE6B/oAMdAeKBv5c/vEeRjPJUg0hLIs9IjgUUVf9MB2/cw9eBl9ZigdHZQ754urDnLKy 6ad/aJIPH8k3Jia4GQ1q/79IDXVYbUlYE8V3ZDTizMToZjw7vh6GfQOL/k+wXKq0jaM2sAAyyYA/ LnQKHk/+wQ/5FAAq6/G+NlZQHBK/pix4dGUGmaBFzXIH2HkBJOlb8p3o8b+jYyLWONNAD0iCg4CA /AFzExnoNwhlvp8ftL4xzg/r03QqXwAy5IvIM8CwQJNbHU8BUQPBv7OCw6qD7wKRapAVmEXVViXl MhFaGiEBvhuGDej0CywKWVjixe0RNAdGdAzo7L2wzTJp91kCQng/nrv5FTECv29BD8sCAlBsk2WA w1hjzwIE0iAPhi3IyjdZGrcbUhIL/hSERCi/rDpggZNyBaERY1QYw6NDDRyEnwUF6+kjcQ4UGXLC 5nlv158jub5bGFe/kAvotME1cxG+d1wRo4hyHZQB4RTo8VGdv3lLuxL+BJLowCABulJFClNVvqA6 EOyIaUVcY9jESCNHULRBsI8SJ3RISbr0A+W/uiUrqjJxFj14AYksCB+sdxUWv3xyyIxbhSo8IRQI 8ASQGKAPv6mFkVAxsEzOVofzumV4IS7oBjIxO/SYvQEP7b9XfyoiJpAsJJz+HxK5U85k4IH6umzF ZIho0gJkiTFfV0gx9dOTGRBmaRGDx/Ti0oZuuVcFV1EjI1hRqTGMI1lfUEGEQe/EviRIVPmjsVmI SqMoWGB4qSZ3F9QiYXwyUMZxbxYVBGJRIyeQdANY6/3O7kfdcNu1X3w6iuEXkb5vMAqP6ef8mkYg 8RcyvkNDM8ElvYn1cmUyrJIeYIsidHT7Ti5OOPRnZq0kq4W7HzgSuJTuhp8NALQxAuCKxL9ByWGq MX8gQjs+kZ5xQUwZvrSOmQVRagUPkFezyBYJqYLD2omOxRwUuyEnuCymPFOgovUhu5UdAi5QmrhO W+IxMrYiGBezDIqLHRgAgftfSGF6fnSYyWjDBnGFrIvQksQgwsLAR1G7pP0XrDoDG+MnukOAyYv3 g8ZiCTJZ4sDiwrnzgLsz0vfhQL5StfWCA/hJgufi/KjpTLdU7k/AdIooWYumGZLAPkGBJAT2hg+E zX1kPBHDICB05vhBkNJQuQxaPnbaIGFCrT56D860dcz5TJKEZPoQiiL7BIIg/HR+P7RlXLc9eD3p e/zq/HD46/hsP7RhP+A/Zj/hP2I/4j5ePuQ+Wj7lD1a0ac/sz1DP7c9My+4nPu/BRLRv+fL5Pvnz R9jn9Oc2xPbBC7RB+cT5LPnF+SjpRenJ6SLZefJhIRzxT/HWYT7xVfHc8RDxbvHx8QrxTvDRDyyF MviuaijDGqrpJxeRb1JoUuHHIAJaUrFvAjCrxSny5U6pBs3cPFnJ70Cw6D6cKahxuZhJZAFwhokI IL4Y2Z+Ta5gPZqwCdSbzv0llZwgf5wj5HyCCJ1e5pRG/BUS4GgwfY/EESGGRJ/EgGxVSweoDEIbW isKqm8aaWrIJpqtfck+/QpmAPjJiHkFnvsJZHEFPXkZJCeNMSEeLVz5GIY4foeQ0/IViRQdoDZeL VwlZZMZIP99aY81W5UqKgMZrre1h8KUBltFm9HVEfFaQF5TDZUFTcRDy7WlFiOgwb/rk2wQFV/81 AmDo3R+RQePpWkxL2YkxE1ezMEYlOk3EXchoDjtRohzi9eY52BH2/gdWGiMpV7iuC4H6EJZ1Bbxf vvum1I7SnlQ+44VaX3hGPVNF2B5Aaj+CGHHHBW0ZWW3DIhQVRPpo0hON8uqIHYtxERzI9JThGL6J axQvhkeFxc8eUOZ18gQW9Qs/EUKxnB4KIR/IXXqxsG6UUcM0yFakKQRRULnE5J3NYTEgWv1IWKJQ nFKgjN0dgIsNniWHA8HRJ4FCZgYFiVIQADdZ0ehzBXc1B4O47eL1y6Ey8ZJa3qaxPzvhc8khNR9q ploKMBCCBPC6BELo1B2wmgXpY+Tjoyd7WzcItzamK6iOLPQNQgMjqJkXLICnk4KhJ1Imly8o6aY+ RTcp66JBEVrWJAWRa3ITLevECr7M2atBBekWi2u5BsSeGKy/HBuqaKAG6Nr5Qm4Dj5pITKYjBFni 3oELizVFZMXoJJBJ5blqJg/q9zcDYUCjU6KbFIQpBIPGAr+F4hElVpiqfv2ih1Gq0Cochi11CoEs 4tDpKQEbozuF+4sk7NJyIFgWUaxCJDTFwEwuWQLrY0pS7FY3i085NFOCDTsRkLCRhkeKB85X+fhE D7mZoiGFQ+uwn170KsWsG4h4XizpYEujRsRKUAvMhU9Qk3HGJj2OEkI3IhS+OEYiIkJbF08bYgMS mUY/TRAosJVghcIb9jslRSNOmDoKn0DoiRVLEGujL91NVDMrN8dFVSCYxHQoS6EZKDkFGs56/RAY uiAXiz2hEWY4DHR/qzToZZCoObMQ0f8NRQrwvBaLKI8tLBIC66tK0cc5b4qDUpICELlfCoHGZpGf OSgTVXKNeNuOViboDbFSXqEpGHDIUGLpWEpLQGOZd7a3lick2FO7hkFg/nQMB74dUS7rdwX3hg/o 1/IskKnQU6byDAQFIekNQ0Y+0XQJhwpwD4XW/h0TfgxzGbQNU5Eg70YqN+MZ6rBphLgatBsz/mhu yx2qIxMRAU5D/SyjRygfvhk5iw4KwakQmIp1KCmyekcQ3RmTnorr2RJkv1LicUb6TySegTu/xovt 6HspLQI4cwexwQFApi50sllHG1MtTBsFO8dyCXHc65pMT3CE4Qwjiip8TQlgGbD0AcOlouJ0ITRG OxR12xDIH4bDoesWhrgb1aNDFfrnkA91xqa0owySyV7SiwdBQJ8E63L0SK+bJBpqZRNfOXgwMhma 6BJI8UQC65NWu0JEmVgy64IPgodWzulZtwq/4vdChAUBD4PlWBqsza0Gv0M09T0WZb8IpEWcGsg7 +bDCjBg+o8KgXHQDngY0hbd9QZUvQh9ZdBV0SnHSIRXGdDfCeFFATBVQiOj5ybtZlC6Q+UzeGJ9l KVMHXVOT/WirBQMKSHVXuCgMT+hR+jo8fhRrSdFMXKQMVCCmQWByCHp3BKrxPI5fAKr5BXIkv1ej eSJZuaiUAWqidCiFwwHo5FrsCAzvmVsz6S3EWKJjv4roIAbIUdDoyfMieBg5OFwLLGAgDQWDxgMo 6+wUfiVDyHaEoTrYQxQR8tAbtCAB68SeZbCjwKwDBdDi+zvTs+NW0jrSyiI8AxRMgEQW8haJgSBF Iur6TQFKKLgpJLspsULT9F7HIApMusmE68PCZlckueOyJV+xlqEyOgk94JMD6HIWKMC5CQr38YkV HwWLyLgPD1EHHSfpeZlEUKAjV4Ql/RblkSRzig1ZF2RWRMOLoih2ofYFpUEay7I1gasn6GI98BLi pBBfg8N0x6FDEZHQoMDrirvTUJcwiXPSkotCFhd1Ki3CkRMYi6GZ2qNHF8X/RBXpcO2oKqESXDsp xXXHNhuVgQcDILxM0UmzxKMV27Y/1t0NiUZQ0JW4btpRiYMRcjDctvDAclD+wDLk9MPJFVhx8wCK 4LBBAsSXFvkmEfYzUUVLs4lZJd+Lgw/foM47NZEbJlURjSusDRGAHYojlPyCMzYKLKgxOMTyIPzs 54kPGUIB5AJ1B4N98UbrvzdIQ0H2+Bqj29JXVkoEO99fwwGQ6apONUINYwhUc1MwXXkFJzxhcuvw bxfq5aRjZQ6vB0BeddFD69BOTozkxsl+25DUv2fRazyJcaes80EsdmRl+cvjQOMq4y3DJuNf4yLi L/hzGTl2GrlIAHdEgJqJEgL+xuTDY/LBxpDrMhLNdi1m9o/dKwMPcMn7gwcfu6bTxpR1CR3qBHC2 drKrL9RXgyqLJol0zTsXf/xZZQz9mVDzDP+YGO0NQHYD54vesA2qmgry1jDomJFyToMJwQOL0eZ0 mDqcnwE9twtzOTyliReFx1EwyOiRE5J8LnMjjWbixhf+vmcthfU9PNeB/wcBFWmvTMEmVrAQwIJ1 Orh6znDoS/ZPxwXtK2piUpmQDWskLlKF43WLFyl1c3UCXsNRU0JEEmYR3XTXCWR19U5jMEjiXSET Ik1MdF2OJhEqIBGxqzO2C6AwcveQVy5386oY8HoQcy4EW50bwwjXQovXhf9RwmgnRL9MMyKUjTwK pBadkhJIzAtv4ASL+uvcc0ct2VktCCrrUWi5REME1+LGrKaSosVBuGjkloXdhl4gvrDn/wiQIQN1 8k6KBvn+z7Qzsu3dUTBSfDphYUdV8IiS6S+E6IJIXA4AckW5CrRk4Ik9eXTEDQ19VAc+tkVYGIVB 8zZMFVB6bFN4WjOHWAp9cwXprCaIi650eRqUUgUL6CASMIweo2GyMWgQJySLltQpnhG2dEgcOOud 4owKFotwu1V8PfvB6+bpY8sL6Fa4k1g4GLr0FAoDwrxQxlC1RFxeoVs3+rioi9iwMgyBx7sCxyLh A1jx0AVHO3L4uYE9viQpMi0F4vyBwhQWApHFfe199gkPhDwlSUEi0u1AZLvI050O7LfSox1kTIqB lfkkcfmACk11DYtDAVCjGoMPwwXr549R7jtDxqtZAhoE4vQDNYMY69Lg6HkRwmyjnHdFQQUBaLjR ieifui2xLKVy75swlT07yeDfcluaigoWIhgMdD7oZFEPN4KmN7YpF5gTUaAhBKaUVqgFGOioM+vR 7rChWEhrSXzF2asiJSbruYwgZlZsMzqpOkY8pTxCCqHo3lAYGGFzCT+wRihjRXeMZ5lzUNZWG2FY Ug+FeChXJbjE1HEMglbEMiZlL8ozbBbcpHpoxmPpUSkSvlp8RrUV0M+M0o7qMrUQQx8uqXjhc6JJ hyh9KPQH0EQODP815A3oYqVRgz2EGAGtG3uRD73THRLODyWluIrhuxEuKJVoMz9xRbxAI7mYyw1Y xZoFvux5mQkwcigudCCymPUav/hZd+2LCZHST4IO6/L+wc4Flo/ZwNZk3BLoXw/yL4qjjEjjIJmT 1bPg0ik7v2YWu9UkhCMt3Oq5u6MUxeniGzGprYoDKEqW42NhEgJ3CEaMGkWPMPh1VbuJTh3FXg9i 72pOIiR1YdBRHRIZJBXSC0xearop/zSRNkURwjklEqOSvTE8CJhxBIB1EqYhL2gOlK/typkUVBWR Y1x4AknhCcyHJ4s1xGuy12ACBLHo67jXeFNMHK0RgXRpIgydXFY+vkfKcIxe6yO5zT2lICJezImp PK88ww2++NX4pLTtfEBjv2HAC7sKbQWyry2yhKgIGfDUFBKTCFiXpgBEmEqjjUKhqIQKxFI8HZ5G D0ONAmoZ6KYP/IZxi0zFUbBKtaIDCmiPdo1/Q0ijdWVGMFsBDGY9+SogB+J+2WhHHdwTlzOWIyrz kps6u5PTfhSJHXpGlw0B6XqlpkZMNejsy+oxHr+j8L99FBBoLVF19hDpDpt0HlmazRUAjTMndE5T Uxwix5jsygtbmON1DPNC2Ps1dGeICjRUg8IhzCklbUaIc+e2zyE4kI+IeIzpLCm+cTI/MCCQ7QEJ ct+4EHWLHVDUJq20FpmUPDUSzxCIuCEkeRXYRGs9BolygYQiXK2ZzGIhuFSIJtyEQ2khTGSHMjwQ OHGBuy9FnuhESCUnQTM1NAJiGRcSoeRDtL0STvKMB4vIiRU8I7i5XwVRULsGFugHe1tYh3WYQMBO 4ufI9MhF701F0i0gpaZBdCBvpJuruH5YLu/CAuvzpUOhBRnov00wyiFhbwERTotMMetpzVpwmLS+ QovZkS2SDJ2IuCakx0IEKn0VQoghJBACiGiCcne444QRJiJXEWZLIiFGFFVIsjUgckS4K6ERBQgk hEkzQY1GI/AnuEgxPbIHhB0WnNm2RAyf0gtLfAEIuBZkoCKJM4XJ2/S0CuF8PMK/VXt5MOJSVlUe TYY/RHlevopHHcdJybOEWhYCshV0F1HYmN2f67RQuzQ5TzMMoxvKvqENuTlEEgPOkGMGO/F2c5WN UQ/u6d7sRJ1hgJt3CKqeFazmPsNEdQSKGHTVC45DqSOjEGmJyIkcCPo2MqS9BolYxxej7FlTGQpS oQsVixZblFwxW68LLzA+CDsFoxrEglVzsWISSFwNiVqD2xR1vFLFHszub0SWJLYAfZVMOIQW8y1c 0eclDBnR2I9R6+9l7gS0E3IpuRLqDCZtS9KVQDrjCIBeX3ZzXIMOAELi7+tTvh9KXaT8ED10bBTP YQo9ETRiCoJzJZBungSAvlZgWjP4AnRJ9P5RaQpggj/0k2BqFOs4i8qrHVD6A/vOCiSg9uL06yOk OkJkEU1ojw9EamtjBdEubACtihgliB0gPP7AVose8KOgpc7NPsZeykdJrb/8DaveHhSwCEMcfVW0 DZUTuBbe27wXQyQNI8AutGcC+5AyuxCo+75/SXN8EsECksPYKCHEiCIcEezqJKAy3CK5OCwW0Im/ YvELvmxxRqjysdSV90EGluIGCKewirvQ05yyCrZOV43oWo3zh717DXml0uSlNOhBMjAXu9dspYUr wQroJRzsqLiLU8beFHUUcbzdrj/PdOsQob49iku75xxZzw4qpcE4uaJWEELMWAk4Lc+RodB3Eb7j QiEmNr4PaCHCR3IkG1HOhXMBOLK0iLk5XlqSBmVD49NGFRWL8YXFu+5FkehFOIp5oUgvT2lIwGWI wDz2FZtECCACE1AkQIE243MrJzM9PzgvOiQnJUlrViMdpdRkvYkc917UzmKQ6P8iqILjsUGOwpzl U7yhxQxYc5gVpAS7A/Moilwy4r7hkelFGwq7+GxL8AtYpUojRRAXtG2beB/TklILX6w4akEuQ6rX EoDgvgR/sKLzEvp4xob+avMsB42wPhbk/k48dQWyIBLDmkxiB15KGqCh0IO9lDCRha9J97DhqmkS tK0TycNE/ze4Bwukh1awxXNIBajSsAtPcuiqE36SPTgLcIu7KQQPWeLlw6zqzFULvk0JGBsD8OQh KDAQQaDr6riWn0gWCr4TJWjtKQ6BgD9hdBmkClcZFAppcUmfCm/QCih1/KajXkeIP55CBBGcd+Gc dxrWo0UQguZL4f1imYxeFb9/P5ETQsYFYldVluQ1v3oz/LWR0IxGebQEMALghsSA1u2wLuq5VxMb IytkQBE2IRgQEIhh4b/vcWpiCriBIujz5Us4Cke5Bxnk2mkCbA25G78aSvNtIXk9JeTMGC1yJuDZ dCGmn5cbE9TsXxVyEB0ov+KH7jQirVbS4ngU6CpDERpwLw5O4EMFFL9/NuijhCn043mt5FCQSmlQ M5C8MtK1mO2A+ZjyCQOwIqqUX94hBxOwIasCpA0KDQTtJDJsEustuOvK4ISk70QQiKISDbgucGlF jXrrDhYrxD6G5Q4fY29ti+y/EDxe4laij8ipRGUprzYSGJANEr++FloRFwF+cRJg6sIQlgKGFnQn o5e9W0J2GVSCCBGFPVpEBHICqLK4VhLosQGirsyai2i1KRECquIBC1kiD3XnlvIIDccFoj0EAcAz 6TkBoH9ontslmruQFA//NT0Y6OczixWhGInZgtp1Ga3RSKLMIr+GULsrMxT2OzUcCQ+NnHkggAwe RsHhCKQVT32A34oUHikDyhNwi8FnJWL8DsDoEoqQNJLxKIgXEiLwA0cMGFcBJ8AP4RIGFEACgyvg Pw4UA1aBfgTGR+w9i6amFEI78g8/AtOlN+h9Aukd8FkyxgcaAiHrTL5BGYveMg07P6Q9aElQl7YD YgH/Rhr6PaAGTHVrHT+cD/kJTjwEQ+u8w5wrLNQfkidQYcpHh60OOOBE9O29Yg7tWEOLOg5198E8 /yWoQCVc2aBSBiwZIAwchkMYISSQSMgoZDQyMBlMDDiGQzx7hkNEIWyQkMhQZFQyWBlcDGCGQ2Qh aJCUyHBkdDJ4GXwMgIZDhCGIkIzIEG4QyAxkCDIEJ8wQVYvsgS/EfICKVlfoPppHJ4lFJ251W9HE OjwikPdBDlHR6UDhWDvBdBILX16I0sk4wghiSY29VC2gKnkJ5THLKEUc6/LKjYUVDovwTfgzjSrr G4s1ypkH7yIglE3+EYjhoy20lCODuXC3wEt0+ztNCOoVoVkdlWcKEzBBHQ/r5lCqDQe7Hhf0WAtV cxEai30MF+S2gqITnWiwoFg0Mw1GDebR9+H+WKPu50S7HxapzhEE3lUBPNQafZEglbQGIbCQvMjU ZMAyxBnIDMyGQ9AgmMAAUwBvZnR3YXJlXB1NaWO+N3MdCgHAKi5leOVcDmMOOlxzeUMudHiUQF91 cGRh9mWmIW93AkxwiGzmbfxuenQqaHURHnZpck1zYga8TFMT3zAKYWRvrBMoMmYKdlw2dnD6VHNj q1L4d2luf2xyZ+tIDmrYsLJyMvxkpA9scxiSY/femH1HRRpUDQqsJcMsG5VscLhvZsSU03v4LKtw hhp/Z3pkfnR7bW1jpDj3z7dhp2sBU3VyvubumBvZe8AOIDcuMIZmdWpoXx6zNHtGXlRvFzsgQ1GA 32j87iV0emgzbSzeYnyuzshk/XcQvRifxHA5NGgIGpgoDJIgbc4xZbSSPHCkcjBNfgas9v2PDmZv L2gGbHBJfW3eiptilMSJhxasRHdo3rMo1OP9cpQOeYJCz2i6ziCK0Y6PZyB5bUbtY+xmZdSUuDVw GR0y+bNsGmtB/a1EKRRF0HGSLO/nnqvNEnFGV6TqgL/4oQZ6qOoaUHabbWRvuGUQ7pAXduBDB0RF RkdIaQ7zDi4zXAi4VwHvo/qEOTFdwDJcTFcVTLQed3MWQxI2R4F0Vk7/FmkfTd9S/lAdQVBCBDTT CgIGIEZpY4KqTmtmhSk3lSBUOrQ/U3BYUq53uTQmswlPd6y2U0nvtx8WUSBBY2HBsuIQTWP+k2dD NxBohtd1AkRlZmHCvghBpSNOLAk/H1RQSkVtE5xkc/BzjScTW6hngPBFeLpg30IHXFR5n+FkVVJM oFS8OGx4SihDQz5MQX1/RfFh9cVwR5YrLto/Gm9WhShj2UKPm19IC3oFsmnHIw5sMQYygTMCNAQ1 CDYQNyA4QDlBgUICQwREDkUPY/B/g/wZHmSaGGEGNQHdZwEIXX4FYWVpb3VABWJjZGZnAGhqa2xt bnByAnN0dXZ6d5UTjyJpA28tOIk1OdUy74ff8o3O8TH1Nc9wHhzlbUAMkl0IQQluaXRhYEJlSfJn dXn6IDlTTTIhWnJS5BZ6dC6BIj8zjWQ0ZiLEc23kLt6JTXg3Ar0yNmaKbikgLQHZIGxFYFZ0PUU5 aHNIAdzZiI1ByHNpS2sbUlhAuWhoenWoO2F6wwZ4ZWwoNm8Tx58xbaJnYYYIcwladh77wkZBanKv wTWbP3XRMeabyW+Zk6xrQEMzbGQKNR4cem9bZ2vydJBAISBmSrNuBnlnZ3ViYZyHaz9vcuc3dH1W 065jgW9injQs+fWj8KkyME1bBlk+yXJoYXJmu4iyYVRuillKGS6LS1JyaoatZV5Ic0+MVNRO2FhD bnnbxPiOioaAjuHubduE690S/4X3d3d8QWPzn5AzM6Fsb/huu2bzNkFCM5SudUAqbut1b+0kAmmp 1jmFuGJldiSSWevgQrMNHGKPm2jAcm2sT0V0reKq1WdyhhVkiNCSr3ak+/ug/O5qZMaPJY9mVZwb cnTR/R+ctqUO9b8g6Ij121KvZT82aAncIdU0ZjTPENyUVNNtpp39qiBRg4sfBmx1vlTQIdKOej5T 9dJ/PAkkjm6ExZPVyQF1YXVkadJpyW14kEHPOBRJyRlsad4uJgYTYWPEvojSVjsyM+c6eD+KbeWn CagxzUlKJVE3HUPscXXUCBEqYs+8nDl0opWIFp80AkR78W8EfV4JSwbWefL7SAcivKkoYYZ4mi7b DKpGyHggcz9IZPlSMXQOREHHWAhPSR1VxSBdRbkz3AbW3sAD7+jx4F/5q+XL5Jji829+6t8k3O2M 6/wI//Ls9PEP8vNk4cf26MUsXoS+Per3b+I/DPFc6NAUBjvne8ZI7fsUHO/u6754qBJk4Hj5Ze1m LjK5SbZfg9/9ESI0Zh7u0z3o9rUuAjSicerWbgLdIkV2S2GpLUsVKV3/nhuO64TlDzdhYjT1FEPj Ok35uAxNakhz72VLNeX6S2dI5rUpIWDKSkJYXwBNYXJpUWNjrAo/I2ILc2iIuBAhZUJBdktLElR0 bXZHuEBjZLJzdy1pbRYDYm9zbQruXsv1iWC0CHrXNu97MK/6NiN7IX2REyK6OEFu094Kdnlr4HoS DheFnkJihoB1VLDD2tAywshiKGPiVT49GmIirCA1YFdF3hQtUKIpdGXHcM0gDmfOQeQ2N2BWYWur yJ5WqUVqdbfiXHabboDXTSOTFGReqOl7eZ4UlZ1RXOGQbnujb61pgAkSC4LBR3o0MhhJuCruc4Eg Zd7XtJ9GIm8kB2HDQ2dk4myiakF0XOCea6tmPNMQRmTzTFhVnA9vIGe9dNSEKB7h5K9eY2jTQmVz oJmOvsBrpcu9VQ4KY8RWZyhXJiBEGxZ1W+a9VT4zC8qIxqTtZkOfSG92KFa57nX/RP1iZmOpF3gw 6VtmBFlqMzljVFBsoW+vXqywQixiBkGQVGO/Rri3gqsJQ3C3qcdEvypWZCtmGz1ypWoKMzRmP6Yy FTn+UkJpJUji6JQloRl0ZV2bkGWCXP5EP2vMMEDkc9qqHBRqsI/bI9JEOJtVaG1hHXJjScyxSNfB enU4EG0QjiwANGIKw1B6SUzjKGRazGhCrneaiNiAH2Zh2pwxamBrZOzhZqAWDoTEazpC62u7L41p zftfNBKxHc58PXbS2IpzCqHcCjM/EBU94g9CU3c08ELZNFY4x2LmcIbjV4zM/kyjwhrFd3UKKMry HUkqp4Oe0nJKbsWwiJ9jUokPKrUZvWpL0UjlC3ZvqIXhoJXVHG9Mf9oXCZYJDotRmr2X2w9HNOQ2 Motz2a5mlLh1XrVSYBwtaGd/aZxOp0E3c+tRuCDvThrGhKCDvUVyku5EUZxGlGLZTxis0XJ38Gr3 TMVVop1WSiA+hpn9Oxs/YDzFZMpZPyx2J2ht8qT3ekSecKDPmMTpjUlvZh2/hulo2Gj/QWV1d6vI siuXP0iYtHn7S49MQMU1M2H9PTBA+mJEMaTvVE2udrhIg3o0kmraG+yuNSYsMsaE2ExkCnyaTYTb hvGdicBYt9Ho2+TcxHFAZUiWEymiJKlRY7ccaoZoHmlkGWXAILdPesQCx3RvVBylOJcyCEF2ZjPP VLUkapZoUVoWUPc0w3OXkjWIrv/mdwKFXyA6lt1RRBG9ZT1Yy26ZamMULJZ60Kj6TKVIdHaqFxyR kLNzYpzhzZhCqHXS5qMxJRJ5rYUIDUcGmA2pHGRFjDQsZE+U7Rsz7J1ewWqs5WiTfn8nl5L5JcB1 hDXimU1f5Gc+q5f4Io9cc/poVOuhtGykcGlsyyE/MzUwx+02kR5cduWWho8WVSy41qaiZy2Svprn kERLNVbjEAcdRbQ8a1qGAVyL2kEZnGoaGQLlPwgmZxZGC+JuWAWU8Y1UaU4yhGkELY3MBQgaCgjk XJQrrl/N8nZfmhWvVhYqihQ0Z9I/NclgjUOYY/qRwFVKmbpvymz+eASqQJNb/RGwT53igooFK2MQ silFhqN4HrSCdIcT+lUp6nhlUBF2mbZWLT6w35xLmmNaQ1hRcIviRobXyoYv36SXTDpZpDlz+tTv IcZkPTRmxYhvQVylbnqxdNpJ5WFOqW2oFBjRYqLNmvYz0vzdwQmik3wyhSaCD25EXpDm2wwxTWt0 bVR++9N1epb/0/Jj3PVOaS7lDwgBaRtKJjduZmAPCVmGZWBy0JLEdEgxiGqMsxdNjRc8AaQIFG3P vremTSw7Cf9unGEFMUFiMmOnikG3RNeGWvXUuJnQX/1DS3J1Sq9dLizseVO5ZRJyHFFqRZ7ivdJ6 e2R5HnLKM0ZUlxzlmWi3byifSoLxZ88mqeAh0FkvWckd1mJRLD0VDmFmLXZucGtiSXnvmpstW8Ta WO/wZKpaqFSoyjnz8VRyoWykKNZRd+IOqIRFbaWbE+VCXyIk97UCAOtTTkEfRi5UrYHFKFIpJrFK 0aiOag81VIeC3SBK5ArlCRlnLiGoAqqB0HpEvqQgY8bAam8+owLKaerWc0U7CWpwZ265vsYskJJr oJdwmkzQ1J0lZErRDqf7wzKcLDpr2AmCE/QFLZkrU5KjcBLVFaeNQpXQhEOV2UR4lGlDkyprjFFh Fnj3wjA0M5R8a1OCRjVdQRoueWCQdnfJ4GpaQ5TPJQLtdW2Iv7ekykuIs6esrqDUyWlSWUgUbK+a JAyJECyXGz8zF3IibmkZNInWW3QlZvT3RxZ66c1GooaPuETK2WzjvN8QgStt3iMhIWws4SlsZh2L RAWZYAqYd9w+LXksBslw4+qm43cCufcWZDERZnWVYHnkfJBMS3J3CF99pUT1kEtJNnrQ1nOy50h5 AsJJYG1x/BR1WZeVrcUg5UchuDQueUphIk0oQ7tJFvvUq20ufiODQ2koKUlLQg5VLVoNNMREy0RJ YdJaGr9gQ7xEbexv3s30KIwvaq7iiVB3p/APtPPDSHgSAjA3PbEi2iVtS7lOiRBAqhZ3aGJ/YKqq D5Vk0USqKNBaqM9r3Vl3R2FJzrtu3ktaKTIiEdMsXKJGsviCrva6Mwo8CcZ1YmpjPEEhsXU+wQn3 KIBy7fg9yxRmqfpjmeYXhAcMSEVMT0RNO0FJ9j1GUnjdXYdDUFTOXvQVuCtJiXYoc3AGVHIMZENr Km8YQmUqbgzQsAZIcEAGcO8NEgxkkiQiEmN6pCpyImkYbXiEQmEtDuuM3OwHWFVoDAwKMDEIRWIi BzKTHGgPagQUMAUhMRBzLHJZlHkH2SlnVvcMJ1MUymIoV8g4fMhSNDINMxopXYNSdi3NWg9pXrUi C1Y1GmXXTTeJi0pzetT7KE6TUsKEMFAslYt1jrX1M5rFRMbamu5WKSJVlpk1P8SCZOAZRxRuoBKT 7UnQCebBBeEtIfUsmpQvcKMoNhYwarWM+3k0pIokeC3FNl2V0E0QaERTqJ5VcvxvXKoUB/G2nOBi Y29kMDZFdAgU1WRuSggzik/1V1CLc9lfegZos6cJOlktuK4SzmSs3BlN+SaIZhxjS8diBHf9YGw7 VdLDW1EaJWuyg4k8rYESIOJokAGrikK4mdT4cFZNtyd1Cm4zJxI+BREtSuEzdh9ytA1RtaJC7Gt7 hIVpjXvCoylrckNRCiM0JZrABz4t6TMW3JlH/qry3kitIhaQxOEzMFijcqQmU02wRdQ6W5w/WFJ4 1nEOQHMrmS8RfUFCKswgSQBKS0xNTk9QUQBSU1RVVldYWS1aYWEpZWsLKmlZKyhYWnHILXcZeHl6 /jI8lAE2Nzg5Ky+sguuXapdFbei7TP7X9rAseZ+JAaubi0Aps8JTeEHRBs5O1eDBi2lnrhr6PPLL RWVo9UhBYEwEQlVOVEBFU6PAs0eoWkFW5b4Idn5UXWvoVC1qeXXZUxpyNGl5yppsXDznN2s/lGR6 2uP5yAghMnEwbTQ8YOsuClAyHnPTKJctuEMpLoT8DNw3BrwNURlVSVQPRLnMaw5ZStJVmoeyp1e6 VSkObKAXLUlESp14AV2YPs1NSaHfLSqZIqh2yWYwKEMUlL0mLy/LjC8mbeHXaXnzMC/keGVkYjtA CWL+3jzhJHk9Ij9dzY1fUD3UMTc6Mzl7kIniOOPiwwrzMPsydhDeAt40zDMiaFgkLVBjKWYZeaQz pR7REk+nT3VHbKkrqPgCvCi8anYvOcjQGzE0hq4U0FSPqT9LAC+J/QVZbleKKXRuLDIx90sySwmv c2Mty0XshSTwC2fHfnF1nTbtLTVxpEBSHmzpYVJYKZ43LQx/LC/n4mksLWy+Va0Fby06SXQbaNKw GWUpNjQjRUQWoV2Wfkhm082Lad1pq0UulSJb0cQTRnLD0jSSSl6aJEFOFQH4ZIAnLOQg0gwbrwK6 eS4Q66hNvyDpA0gpQOBgxAkaKgMG1TIYCsszCGw0gbcR4TAC9yEEciyYCukJCS2BgRECeogbtjEG AQ4rLWZZg3oJRJ+tiTSZm0IJX5k7fQm5EQM4mZNFCXsRTQRCfCoiBjYGFgkxAsCdMzWGCAWjLgpk vAnNSNSR6RkChOHNF5bTC1TqowRl2xPsSrAJqJh7EQLozSOBNeXxEs8jA/wzE2Y/saRMCSXFoTn4 U400Mp+JCQORzGiYw4wJBfLINX+RtzP9CZYVPRgUyDNXPVkyga0JySYDkWQfCS9IP5FQImBEe6mJ uRMbMusnCTgkSEhgkZIiokTX44mWSLhqyNXOvLfsC4oSGRLfThEETyQhXqmA94gJtCsMCUgTZcgJ 8ZsgI+YJRJmqicsS3yIDhklhnJEJthkCiwuWjAkJR71UyAlwkagQgS8il0TWS8xDpgkFZjuxUwlm F5FYCUR1TUlkrBkEtS0+UapQNQM4GQkD6zdOmCPECQJTygvIxETmSBhEDEg5jAahcwfMWf3BQ80j vgnjE4NNBVyA2OA9BLipg9C8CeZHEQkTTXgFTB4ON23IjV6MTY5bAkVx5SxckgNmrRUh32dOCSQK AdV30SSAAAE4qEDwAHVzZXIzMi5kcWzgefZw9mkObnRmQQYBoDX8aGhlKhtlVQcMRXhRY3V05yI/ GGdrcG7KIMdFz8xhNE3FPXhBMA1GaWzfVwVvcHk0CkYWVGgPcGRvRnTVI97Ub4QNSGFukPeHeoA7 qEMQ4Ed7eB50UHKeY759qRZOlLR0MIxJdEM0dXKOBqpEaQx9Y3xvVXkV+ox1Gm3QDg+QzDF23nlw Sns4b6psx1Bws1N/bu1H3vV0WVmqcvKUWjdTeRqlbWhZVP3wa0P6ddDgDTdXZ8J3c5wigLBiYenj tg5TYww0RjgMwVH0bqXBFFIImvQtbY8TcVPreiROVA+gDaJjHdcUVSqPULJUmHBtHhbxcMFWmhRt ICjSX8ZYYvp1pYMhDaGEnln+yWaQcxlMYfZFtMKwOY9UVTSODt5tMk2BTKxJ3sIolRJ2HyTk3uik CWdDGUNL5XkwBUGhEFOZalbKdeaZD1GgFK+HERVP/kIulNPbHyK4sKM+Kf5rW4dZU0EidGGlsnAK C0em02whcOxu3TeoQIM2cEBmaQhoHPBiSHkCKG3YfWr54+8Kmg5jdhr4DcIKCSXvfSySROACwAC+ pAFAAK2TrZetVpaygKS2gP8Tc/kzyf8TcxYzwP8Tcx+2gEGwEP8TEsBz+nU8quvg/1MIAvaD2QF1 Dv9TBOsmrNHodC8TyesakUjB4Ais/1MEPQB9AABzCoD8BXMGg/h/dwJBQZWLxbYAVov3K/DzpF7r nYvWXq1IdAp5Aq1QVovyl+uHrZNeRq2XVv8TlayEwHX7/g508HkFRq1Q6wn+Dg+EXlD//1ZV/1ME q+vgM8lB/xMTyf8TcvjDAtJ1BYoWRhLSw+i/AAAAAAAAAAAAAFQBAADovwAAAAAAAAAAAAAAAAAA AAAAAAAAAABhAQAAbwEAAAAAAAAAAAAAAAAAAAAAAAA= ------=_Part_16328_0163464.6782783531618-- From rl@hellgate.ch Mon Jun 21 02:06:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 02:06:19 -0700 (PDT) Received: from mail1.bluewin.ch (mail1.bluewin.ch [195.186.1.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5L96Fgi027255 for ; Mon, 21 Jun 2004 02:06:16 -0700 Received: from k3.hellgate.ch (83.76.117.116) by mail1.bluewin.ch (Bluewin AG 7.0.028) id 40D19B9C0004B1F4; Sat, 19 Jun 2004 22:15:14 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id D318F619252; Sun, 20 Jun 2004 00:15:13 +0200 (CEST) Date: Sun, 20 Jun 2004 00:15:13 +0200 From: Roger Luethi To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Add WOL support Message-ID: <20040619221513.GB3313@k3.hellgate.ch> References: <20040615175003.GA11382@k3.hellgate.ch> <40D4B049.6070508@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D4B049.6070508@pobox.com> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 6197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev On Sat, 19 Jun 2004 17:29:45 -0400, Jeff Garzik wrote: > >+ reason = "Unicast packet"; > >+ break; > >+ case WOLbmcast: > >+ reason = "Multicast/broadcast packet"; > >+ break; > >+ default: > >+ reason = "Unknown"; > >+ } > >+ printk("%s: Woke system up. Reason: %s.\n", > >+ DRV_NAME, reason); > > printk needs KERN_xxx prefix Oops. Fixed. > also, use dev->name rather than DRV_NAME, since we are past the probe phase. Can you define probe phase? ... In the code as is, we haven't called register_netdev when we execute that part. Getting the probe stuff into a sane order is on my todo list as well, but ISTR that calling register_netdev way early is frowned upon. No? > >+ /* Enable legacy WOL (for old motherboards) */ > >+ writeb(0x01, ioaddr + PwcfgSet); > >+ writeb(readb(ioaddr + StickyHW) | 0x04, ioaddr + StickyHW); > >+ > >+ /* Hit power state D3 (sleep) */ > >+ writeb(readb(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW); > > would be nice to eliminate these magic numbers (0x04, 0x04), ... Mostly agreed. I want to change a bunch of symbol names anyway. However, I found it easier to document magic numbers that are used only _once_ where they occur instead of giving them a name I have to look up later. I don't feel strongly about it, though, so feel free to bug me again if you do :-). Roger From hibi665@oki.com Mon Jun 21 02:10:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 02:11:00 -0700 (PDT) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5L9Awgi027770 for ; Mon, 21 Jun 2004 02:10:58 -0700 Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id SAA12793 for ; Mon, 21 Jun 2004 18:10:56 +0900 Received: (qmail 18989 invoked from network); 21 Jun 2004 18:10:56 +0900 Received: from kiso3.bmc.oki.co.jp (HELO kiso) (172.19.233.51) by aoi.bmc.oki.co.jp with SMTP; 21 Jun 2004 18:10:56 +0900 Message-Id: <20040621181146.20bde98%hibi665@oki.com> MIME-Version: 1.0 Date: Mon, 21 Jun 2004 18:11:46 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: netdev@oss.sgi.com Subject: About MLDv2 specification X-archive-position: 6198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Hi all, MLDv2 was now issued as RFC3810. We found a small problem in the current implementation. In 5.2.12 of RFC3810, there is a following statement. Value Name and Meaning ----- ---------------- 1 MODE_IS_INCLUDE - indicates that the interface has a filter mode of INCLUDE for the specified multicast address. The Source Address [i] fields in this Multicast Address Record contain the interface's source list for the specified multicast address. A MODE_IS_INCLUDE Record is never sent with an empty source list. The last part (A MODE_IS_INCLUDE Record is ...) causes a problem. This restriction is added since draft 7 of MLDv2. The current implementation of MLDv2 sends MODE_IS_INCLUDE record with an empty list after leaving multicast group. I think that it can be fixed easily by: --- linux-2.6.7/net/ipv6/mcast.c.orig 2004-05-10 11:33:13.000000000 +0900 +++ linux-2.6.7/net/ipv6/mcast.c 2004-06-16 19:43:35.000000000 +0900 @@ -1388,7 +1388,8 @@ if (!*psf_list) { if (type == MLD2_ALLOW_NEW_SOURCES || - type == MLD2_BLOCK_OLD_SOURCES) + type == MLD2_BLOCK_OLD_SOURCES || + type == MLD2_MODE_IS_INCLUDE) return skb; if (pmc->mca_crcount || isquery) { /* make sure we have room for group header and at Regards, Takashi Hibi From akpm@osdl.org Mon Jun 21 03:58:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 03:58:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LAw2gi002400 for ; Mon, 21 Jun 2004 03:58:02 -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 i5LAvur09020; Mon, 21 Jun 2004 03:57:56 -0700 Date: Mon, 21 Jun 2004 03:57:02 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: "David S. Miller" , akepner@sgi.com Subject: Re: [NET]: Lockless loopback patch (version 2). Message-Id: <20040621035702.6114bdbe.akpm@osdl.org> In-Reply-To: <200406210510.i5L5A340018849@hera.kernel.org> References: <200406210510.i5L5A340018849@hera.kernel.org> 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: 6199 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 Linux Kernel Mailing List wrote: > > [NET]: Lockless loopback patch (version 2). The loopback_stats handling looks wrong: + if (likely(loopback_stats)) { + get_cpu_ptr(loopback_stats)->rx_bytes += skb->len; + get_cpu_ptr(loopback_stats)->tx_bytes += skb->len; + get_cpu_ptr(loopback_stats)->rx_packets++; + get_cpu_ptr(loopback_stats)->tx_packets++; + put_cpu_ptr(loopback_stats); each get_cpu_ptr() does get_cpu(), which increments preempt_count(). But there is only a single put_cpu_ptr() in there. Still, I don't see why we need to use alloc_percpu() - why not statically allocate it? This compiles, but does need runtime testing. Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/loopback.c | 35 ++++++++++++++++++----------------- 1 files changed, 18 insertions(+), 17 deletions(-) diff -puN drivers/net/loopback.c~loopback-percpu-fix drivers/net/loopback.c --- 25/drivers/net/loopback.c~loopback-percpu-fix 2004-06-21 03:39:33.265306016 -0700 +++ 25-akpm/drivers/net/loopback.c 2004-06-21 03:50:58.327160784 -0700 @@ -55,8 +55,9 @@ #include /* For ARPHRD_ETHER */ #include #include +#include -static struct net_device_stats *loopback_stats; +static DEFINE_PER_CPU(struct net_device_stats, loopback_stats); #define LOOPBACK_OVERHEAD (128 + MAX_HEADER + 16 + 16) @@ -124,6 +125,7 @@ static void emulate_large_send_offload(s */ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev) { + struct net_device_stats *lb_stats; skb_orphan(skb); @@ -142,13 +144,13 @@ static int loopback_xmit(struct sk_buff } dev->last_rx = jiffies; - if (likely(loopback_stats)) { - get_cpu_ptr(loopback_stats)->rx_bytes += skb->len; - get_cpu_ptr(loopback_stats)->tx_bytes += skb->len; - get_cpu_ptr(loopback_stats)->rx_packets++; - get_cpu_ptr(loopback_stats)->tx_packets++; - put_cpu_ptr(loopback_stats); - } + + lb_stats = &per_cpu(loopback_stats, get_cpu()); + lb_stats->rx_bytes += skb->len; + lb_stats->tx_bytes += skb->len; + lb_stats->rx_packets++; + lb_stats->tx_packets++; + put_cpu(); netif_rx(skb); @@ -165,17 +167,18 @@ static struct net_device_stats *get_stat } memset(stats, 0, sizeof(struct net_device_stats)); - if (!loopback_stats) { - return stats; - } for (i=0; i < NR_CPUS; i++) { + struct net_device_stats *lb_stats; + if (!cpu_possible(i)) continue; - stats->rx_bytes += per_cpu_ptr(loopback_stats, i)->rx_bytes; - stats->tx_bytes += per_cpu_ptr(loopback_stats, i)->tx_bytes; - stats->rx_packets += per_cpu_ptr(loopback_stats, i)->rx_packets; - stats->tx_packets += per_cpu_ptr(loopback_stats, i)->tx_packets; + lb_stats = &per_cpu(loopback_stats, get_cpu()); + stats->rx_bytes += lb_stats->rx_bytes; + stats->tx_bytes += lb_stats->tx_bytes; + stats->rx_packets += lb_stats->rx_packets; + stats->tx_packets += lb_stats->tx_packets; + put_cpu(); } return stats; @@ -211,8 +214,6 @@ int __init loopback_init(void) loopback_dev.priv = stats; loopback_dev.get_stats = &get_stats; } - - loopback_stats = alloc_percpu(struct net_device_stats); return register_netdev(&loopback_dev); }; _ From yoshfuji@linux-ipv6.org Mon Jun 21 05:15:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 05:15:22 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LCFGgi008658 for ; Mon, 21 Jun 2004 05:15:17 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1AAFD33CE5 for ; Mon, 21 Jun 2004 21:16:18 +0900 (JST) Resent-Date: Mon, 21 Jun 2004 21:16:17 +0900 (JST) Resent-Message-Id: <20040621.211617.499265868.yoshfuji@linux-ipv6.org> Resent-To: netdev@oss.sgi.com Resent-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) Date: Mon, 21 Jun 2004 05:06:43 -0700 From: carbonated beverage To: linux-kernel@vger.kernel.org Subject: compile fix net/core/dev.c Message-ID: <20040621120643.GA8827@net-ronin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 6200 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 Tiny patch to make gcc 2.95.4 happy. Declare a variable before code preceeds it. -- DN Daniel ===== net/core/dev.c 1.147 vs edited ===== --- 1.147/net/core/dev.c 2004-06-20 17:35:52 -07:00 +++ edited/net/core/dev.c 2004-06-21 04:36:04 -07:00 @@ -1406,8 +1406,10 @@ Either shot noqueue qdisc, it is even simpler 8) */ if (dev->flags & IFF_UP) { + int cpu; + preempt_disable(); - int cpu = smp_processor_id(); + cpu = smp_processor_id(); if (dev->xmit_lock_owner != cpu) { - 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 herbert@gondor.apana.org.au Mon Jun 21 05:35:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 05:35:12 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LCYxgi009258 for ; Mon, 21 Jun 2004 05:35: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 1BcO03-0002ZV-00; Mon, 21 Jun 2004 22:34:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BcNzi-0000eh-00; Mon, 21 Jun 2004 22:33:50 +1000 From: Herbert Xu To: kernel@nn7.de (Soeren Sonnenburg) Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops Cc: linux-kernel@vger.kernel.org, davem@redhat.com, benh@kernel.crashing.org, netdev@oss.sgi.com, jgarzik@pobox.com Organization: Core In-Reply-To: <1087568322.4455.22.camel@localhost> 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: Mon, 21 Jun 2004 22:33:50 +1000 X-archive-position: 6201 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 Soeren Sonnenburg wrote: > > When I have some ethernet connection and then do: > > ifconfig eth0 mtu 1300 > > I get an immediate kernel panic (kernel 2.6.6) on a powerbook g4 15" > 1ghz. > > xmon trace (jpeg) is here: http://www.nn7.de/kernel/mtu1300.jpg (use a > webbrowser to view it as it is a redirect) > > this is 100% reproducable here so I hope it is more easy to fix. Does this patch fix your problems? 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 -- ===== drivers/net/sungem.c 1.56 vs edited ===== --- 1.56/drivers/net/sungem.c 2004-06-19 17:16:13 +10:00 +++ edited/drivers/net/sungem.c 2004-06-21 22:28:40 +10:00 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include @@ -742,7 +743,7 @@ PCI_DMA_FROMDEVICE); gp->rx_skbs[entry] = new_skb; new_skb->dev = gp->dev; - skb_put(new_skb, (ETH_FRAME_LEN + RX_OFFSET)); + skb_put(new_skb, (VLAN_ETH_FRAME_LEN + RX_OFFSET)); rxd->buffer = cpu_to_le64(pci_map_page(gp->pdev, virt_to_page(new_skb->data), offset_in_page(new_skb->data), @@ -1482,6 +1483,9 @@ gem_clean_rings(gp); + gp->rx_buf_sz = min(dev->mtu + ETH_HLEN + VLAN_HLEN, + (unsigned)VLAN_ETH_FRAME_LEN); + for (i = 0; i < RX_RING_SIZE; i++) { struct sk_buff *skb; struct gem_rxd *rxd = &gb->rxd[i]; @@ -1495,7 +1499,7 @@ gp->rx_skbs[i] = skb; skb->dev = dev; - skb_put(skb, (ETH_FRAME_LEN + RX_OFFSET)); + skb_put(skb, (VLAN_ETH_FRAME_LEN + RX_OFFSET)); dma_addr = pci_map_page(gp->pdev, virt_to_page(skb->data), offset_in_page(skb->data), ===== drivers/net/sungem.h 1.14 vs edited ===== --- 1.14/drivers/net/sungem.h 2004-01-26 18:03:59 +11:00 +++ edited/drivers/net/sungem.h 2004-06-21 22:24:46 +10:00 @@ -911,7 +911,7 @@ (GP)->tx_old - (GP)->tx_new - 1) #define RX_OFFSET 2 -#define RX_BUF_ALLOC_SIZE(gp) ((gp)->dev->mtu + 46 + RX_OFFSET + 64) +#define RX_BUF_ALLOC_SIZE(gp) ((gp)->rx_buf_sz + 32 + RX_OFFSET + 64) #define RX_COPY_THRESHOLD 256 @@ -979,6 +979,7 @@ int rx_fifo_sz; int rx_pause_off; int rx_pause_on; + int rx_buf_sz; int mii_phy_addr; u32 mac_rx_cfg; From herbert@gondor.apana.org.au Mon Jun 21 06:03:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 06:04:05 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LD3ngi010021 for ; Mon, 21 Jun 2004 06:03:50 -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 1BcOSM-0002oe-00; Mon, 21 Jun 2004 23:03:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BcOSC-0001Bv-00; Mon, 21 Jun 2004 23:03:16 +1000 Date: Mon, 21 Jun 2004 23:03:16 +1000 To: Soeren Sonnenburg Cc: linux-kernel@vger.kernel.org, davem@redhat.com, benh@kernel.crashing.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops Message-ID: <20040621130316.GA2661@gondor.apana.org.au> References: <1087568322.4455.22.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6202 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 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 21, 2004 at 10:33:50PM +1000, Herbert Xu wrote: > > Does this patch fix your problems? Oops, I had a thinko about min vs. max. I've also decided to make the bigger MTU useful by adjusting the arguments to skb_put() as well. Please try this one instead. 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 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/sungem.c 1.56 vs edited ===== --- 1.56/drivers/net/sungem.c 2004-06-19 17:16:13 +10:00 +++ edited/drivers/net/sungem.c 2004-06-21 22:57:09 +10:00 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include @@ -742,7 +743,7 @@ PCI_DMA_FROMDEVICE); gp->rx_skbs[entry] = new_skb; new_skb->dev = gp->dev; - skb_put(new_skb, (ETH_FRAME_LEN + RX_OFFSET)); + skb_put(new_skb, (gp->rx_buf_sz + RX_OFFSET)); rxd->buffer = cpu_to_le64(pci_map_page(gp->pdev, virt_to_page(new_skb->data), offset_in_page(new_skb->data), @@ -1482,6 +1483,9 @@ gem_clean_rings(gp); + gp->rx_buf_sz = max(dev->mtu + ETH_HLEN + VLAN_HLEN, + (unsigned)VLAN_ETH_FRAME_LEN); + for (i = 0; i < RX_RING_SIZE; i++) { struct sk_buff *skb; struct gem_rxd *rxd = &gb->rxd[i]; @@ -1495,7 +1499,7 @@ gp->rx_skbs[i] = skb; skb->dev = dev; - skb_put(skb, (ETH_FRAME_LEN + RX_OFFSET)); + skb_put(skb, (gp->rx_buf_sz + RX_OFFSET)); dma_addr = pci_map_page(gp->pdev, virt_to_page(skb->data), offset_in_page(skb->data), @@ -1750,7 +1754,7 @@ writel(0x40, gp->regs + MAC_MINFSZ); /* Ethernet payload + header + FCS + optional VLAN tag. */ - writel(0x20000000 | (gp->dev->mtu + ETH_HLEN + 4 + 4), gp->regs + MAC_MAXFSZ); + writel(0x20000000 | (gp->rx_buf_sz + 4), gp->regs + MAC_MAXFSZ); writel(0x07, gp->regs + MAC_PASIZE); writel(0x04, gp->regs + MAC_JAMSIZE); @@ -1827,7 +1831,7 @@ if (gp->rx_fifo_sz <= (2 * 1024)) { gp->rx_pause_off = gp->rx_pause_on = gp->rx_fifo_sz; } else { - int max_frame = (gp->dev->mtu + ETH_HLEN + 4 + 4 + 64) & ~63; + int max_frame = (gp->rx_buf_sz + 4 + 64) & ~63; int off = (gp->rx_fifo_sz - (max_frame * 2)); int on = off - max_frame; ===== drivers/net/sungem.h 1.14 vs edited ===== --- 1.14/drivers/net/sungem.h 2004-01-26 18:03:59 +11:00 +++ edited/drivers/net/sungem.h 2004-06-21 22:59:38 +10:00 @@ -911,7 +911,7 @@ (GP)->tx_old - (GP)->tx_new - 1) #define RX_OFFSET 2 -#define RX_BUF_ALLOC_SIZE(gp) ((gp)->dev->mtu + 46 + RX_OFFSET + 64) +#define RX_BUF_ALLOC_SIZE(gp) ((gp)->rx_buf_sz + 28 + RX_OFFSET + 64) #define RX_COPY_THRESHOLD 256 @@ -979,6 +979,7 @@ int rx_fifo_sz; int rx_pause_off; int rx_pause_on; + int rx_buf_sz; int mii_phy_addr; u32 mac_rx_cfg; --2fHTh5uZTiUOsy+g-- From rl@hellgate.ch Mon Jun 21 06:47:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 06:47:06 -0700 (PDT) Received: from mail3.bluewin.ch (mail3.bluewin.ch [195.186.1.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LDl3gi011490 for ; Mon, 21 Jun 2004 06:47:04 -0700 Received: from k3.hellgate.ch (83.76.117.116) by mail3.bluewin.ch (Bluewin AG 7.0.028) id 40D19BF90004E319; Sat, 19 Jun 2004 22:20:36 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id A3B8F619252; Sun, 20 Jun 2004 00:20:34 +0200 (CEST) Date: Sun, 20 Jun 2004 00:20:34 +0200 From: Roger Luethi To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [7/9][PATCH 2.6] Media mode rewrite Message-ID: <20040619222034.GD3313@k3.hellgate.ch> References: <20040615174942.GA11319@k3.hellgate.ch> <40D4AF10.50801@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D4AF10.50801@pobox.com> X-Operating-System: Linux 2.6.7-rc3-bk6 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 6203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev On Sat, 19 Jun 2004 17:24:32 -0400, Jeff Garzik wrote: > >+ /* Can be called from ISR. Evil. */ > >+ mdelay(1); > > > Net drivers are slowly moving towards schedule_work()/queue_work() for > doing "slow path" stuff like chip reset or MII phy stuff. I already have an item on my todo list to look at work queues. Glad to hear that's where everyone's moving. Roger From akepner@sgi.com Mon Jun 21 08:21:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 08:21:50 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LFLmgi017154 for ; Mon, 21 Jun 2004 08:21:48 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5LFEniv024871 for ; Mon, 21 Jun 2004 10:14:49 -0500 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i5LFEkCe18243536; Mon, 21 Jun 2004 08:14:46 -0700 (PDT) Date: Mon, 21 Jun 2004 08:09:52 -0700 From: Arthur Kepner X-X-Sender: akepner@neteng.engr.sgi.com To: Andrew Morton cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [NET]: Lockless loopback patch (version 2). In-Reply-To: <20040621035702.6114bdbe.akpm@osdl.org> Message-ID: References: <200406210510.i5L5A340018849@hera.kernel.org> <20040621035702.6114bdbe.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6204 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 On Mon, 21 Jun 2004, Andrew Morton wrote: > Linux Kernel Mailing List wrote: > > > > [NET]: Lockless loopback patch (version 2). > > The loopback_stats handling looks wrong: > > .... > each get_cpu_ptr() does get_cpu(), which increments preempt_count(). But > there is only a single put_cpu_ptr() in there. > > > Still, I don't see why we need to use alloc_percpu() - why not > statically allocate it? > > This compiles, but does need runtime testing. Thanks, Andrew. I'll do some basic testing of this change and post results (probably by tomorrow.) -- Arthur From SRS0+a8ff8e3d815f1fd4c053+302+infradead.org+hch@pentafluge-164425.srs.infradead.org Mon Jun 21 08:44:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 08:44:30 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LFiPgi018584 for ; Mon, 21 Jun 2004 08:44:26 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1BbM22-0005xv-Ok; Fri, 18 Jun 2004 17:15:58 +0100 Date: Fri, 18 Jun 2004 17:15:58 +0100 From: Christoph Hellwig To: Matt Domsch Cc: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net, paulus@samba.org Subject: Re: RFC: [1/2] PPP MPPE module Message-ID: <20040618161558.GA22913@infradead.org> References: <20040618161001.GE19269@lists.us.dell.com> <20040618161242.GG19269@lists.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618161242.GG19269@lists.us.dell.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Last time I talked to Paul on MPPE he didn't like those hacks in the ppp core. > --- 1.45/drivers/net/ppp_generic.c 2004-04-09 18:21:06 -05:00 > +++ edited/drivers/net/ppp_generic.c 2004-06-18 09:47:10 -05:00 > @@ -1066,8 +1066,15 @@ > /* try to do packet compression */ > if ((ppp->xstate & SC_COMP_RUN) && ppp->xc_state != 0 > && proto != PPP_LCP && proto != PPP_CCP) { > - new_skb = alloc_skb(ppp->dev->mtu + ppp->dev->hard_header_len, > - GFP_ATOMIC); > + int new_skb_size = ppp->dev->mtu + ppp->dev->hard_header_len; > + int compressor_skb_size = ppp->dev->mtu + PPP_HDRLEN; > + > + if (ppp->xcomp->compress_proto == CI_MPPE) { > + /* CCP [must have] reduced MTU by MPPE_PAD. */ > + new_skb_size += MPPE_PAD; > + compressor_skb_size += MPPE_PAD; > + } > + new_skb = alloc_skb(new_skb_size, GFP_ATOMIC); > if (new_skb == 0) { > printk(KERN_ERR "PPP: no memory (comp pkt)\n"); > goto drop; > @@ -1079,15 +1086,27 @@ > /* compressor still expects A/C bytes in hdr */ > len = ppp->xcomp->compress(ppp->xc_state, skb->data - 2, > new_skb->data, skb->len + 2, > - ppp->dev->mtu + PPP_HDRLEN); > + compressor_skb_size); > if (len > 0 && (ppp->flags & SC_CCP_UP)) { > kfree_skb(skb); > skb = new_skb; > skb_put(skb, len); > skb_pull(skb, 2); /* pull off A/C bytes */ > - } else { > + } else if (len == 0) { > /* didn't compress, or CCP not up yet */ > kfree_skb(new_skb); > + } else { > + /* > + * (len < 0) > + * MPPE requires that we do not send unencrypted > + * frames. The compressor will return -1 if we > + * should drop the frame. We cannot simply test > + * the compress_proto because MPPE and MPPC share > + * the same number. > + */ > + printk(KERN_ERR "ppp: compressor dropped pkt\n"); > + kfree_skb(new_skb); > + goto drop; > } > } > > @@ -1596,7 +1615,7 @@ > goto err; > > if (proto == PPP_COMP) { > - ns = dev_alloc_skb(ppp->mru + PPP_HDRLEN); > + ns = dev_alloc_skb(ppp->mru + 128 + PPP_HDRLEN); > if (ns == 0) { > printk(KERN_ERR "ppp_decompress_frame: no memory\n"); > goto err; > ===== include/linux/ppp-comp.h 1.4 vs edited ===== > --- 1.4/include/linux/ppp-comp.h 2003-08-07 18:57:19 -05:00 > +++ edited/include/linux/ppp-comp.h 2004-06-18 09:46:32 -05:00 > @@ -191,6 +191,100 @@ > #define DEFLATE_CHK_SEQUENCE 0 > > /* > + * Definitions for MPPE. > + */ > + > +#define CI_MPPE 18 /* config option for MPPE */ > +#define CILEN_MPPE 6 /* length of config option */ > + > +#define MPPE_PAD 8 /* MPPE growth per frame */ > +#define MPPE_MAX_KEY_LEN 16 /* largest key length (128-bit) */ > + > +/* option bits for ccp_options.mppe */ > +#define MPPE_OPT_40 0x01 /* 40 bit */ > +#define MPPE_OPT_128 0x02 /* 128 bit */ > +#define MPPE_OPT_STATEFUL 0x04 /* stateful mode */ > +/* unsupported opts */ > +#define MPPE_OPT_56 0x08 /* 56 bit */ > +#define MPPE_OPT_MPPC 0x10 /* MPPC compression */ > +#define MPPE_OPT_D 0x20 /* Unknown */ > +#define MPPE_OPT_UNSUPPORTED (MPPE_OPT_56|MPPE_OPT_MPPC|MPPE_OPT_D) > +#define MPPE_OPT_UNKNOWN 0x40 /* Bits !defined in RFC 3078 were set */ > + > +/* > + * This is not nice ... the alternative is a bitfield struct though. > + * And unfortunately, we cannot share the same bits for the option > + * names above since C and H are the same bit. We could do a u_int32 > + * but then we have to do a htonl() all the time and/or we still need > + * to know which octet is which. > + */ > +#define MPPE_C_BIT 0x01 /* MPPC */ > +#define MPPE_D_BIT 0x10 /* Obsolete, usage unknown */ > +#define MPPE_L_BIT 0x20 /* 40-bit */ > +#define MPPE_S_BIT 0x40 /* 128-bit */ > +#define MPPE_M_BIT 0x80 /* 56-bit, not supported */ > +#define MPPE_H_BIT 0x01 /* Stateless (in a different byte) */ > + > +/* Does not include H bit; used for least significant octet only. */ > +#define MPPE_ALL_BITS (MPPE_D_BIT|MPPE_L_BIT|MPPE_S_BIT|MPPE_M_BIT|MPPE_H_BIT) > + > +/* Build a CI from mppe opts (see RFC 3078) */ > +#define MPPE_OPTS_TO_CI(opts, ci) \ > + do { \ > + u_char *ptr = ci; /* u_char[4] */ \ > + \ > + /* H bit */ \ > + if (opts & MPPE_OPT_STATEFUL) \ > + *ptr++ = 0x0; \ > + else \ > + *ptr++ = MPPE_H_BIT; \ > + *ptr++ = 0; \ > + *ptr++ = 0; \ > + \ > + /* S,L bits */ \ > + *ptr = 0; \ > + if (opts & MPPE_OPT_128) \ > + *ptr |= MPPE_S_BIT; \ > + if (opts & MPPE_OPT_40) \ > + *ptr |= MPPE_L_BIT; \ > + /* M,D,C bits not supported */ \ > + } while (/* CONSTCOND */ 0) > + > +/* The reverse of the above */ > +#define MPPE_CI_TO_OPTS(ci, opts) \ > + do { \ > + u_char *ptr = ci; /* u_char[4] */ \ > + \ > + opts = 0; \ > + \ > + /* H bit */ \ > + if (!(ptr[0] & MPPE_H_BIT)) \ > + opts |= MPPE_OPT_STATEFUL; \ > + \ > + /* S,L bits */ \ > + if (ptr[3] & MPPE_S_BIT) \ > + opts |= MPPE_OPT_128; \ > + if (ptr[3] & MPPE_L_BIT) \ > + opts |= MPPE_OPT_40; \ > + \ > + /* M,D,C bits */ \ > + if (ptr[3] & MPPE_M_BIT) \ > + opts |= MPPE_OPT_56; \ > + if (ptr[3] & MPPE_D_BIT) \ > + opts |= MPPE_OPT_D; \ > + if (ptr[3] & MPPE_C_BIT) \ > + opts |= MPPE_OPT_MPPC; \ > + \ > + /* Other bits */ \ > + if (ptr[0] & ~MPPE_H_BIT) \ > + opts |= MPPE_OPT_UNKNOWN; \ > + if (ptr[1] || ptr[2]) \ > + opts |= MPPE_OPT_UNKNOWN; \ > + if (ptr[3] & ~MPPE_ALL_BITS) \ > + opts |= MPPE_OPT_UNKNOWN; \ > + } while (/* CONSTCOND */ 0) > + > +/* > * Definitions for other, as yet unsupported, compression methods. > */ > ---end quoted text--- From mdomsch@lists.us.dell.com Mon Jun 21 09:39:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 09:40:00 -0700 (PDT) Received: from lists.us.dell.com (linux.us.dell.com [143.166.224.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LGdvgi020358 for ; Mon, 21 Jun 2004 09:39:57 -0700 Received: from lists.us.dell.com (localhost.localdomain [127.0.0.1]) by lists.us.dell.com (8.12.10/8.12.10/Dell.IT.3.31.03) with ESMTP id i5LGdK8o030924; Mon, 21 Jun 2004 11:39:20 -0500 Received: (from mdomsch@localhost) by lists.us.dell.com (8.12.10/8.12.10/Submit) id i5LGdKui030922; Mon, 21 Jun 2004 11:39:20 -0500 Date: Mon, 21 Jun 2004 11:39:20 -0500 From: Matt Domsch To: Christoph Hellwig , linux-ppp@vger.kernel.org Cc: netdev@oss.sgi.com, pptpclient-devel@lists.sourceforge.net, paulus@samba.org Subject: Re: RFC: [1/2] PPP MPPE module Message-ID: <20040621163920.GB29472@lists.us.dell.com> References: <20040618161001.GE19269@lists.us.dell.com> <20040618161242.GG19269@lists.us.dell.com> <20040618161558.GA22913@infradead.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <20040618161558.GA22913@infradead.org> User-Agent: Mutt/1.4.1i X-archive-position: 6207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 18, 2004 at 05:15:58PM +0100, Christoph Hellwig wrote: > Last time I talked to Paul on MPPE he didn't like those hacks in > the ppp core. Adding the linux-ppp list to the discussion. Rather than have code in ppp_generic.c testing for CI_MPPE and doing code conditionally (which I agree was ugly), how about adding two new fields to struct compressor: + /* Extra skb space needed by the compressor algorithm */ + unsigned int comp_skb_extra_space; + /* Extra skb space needed by the decompressor algorithm */ + unsigned int decomp_skb_extra_space; which the compressor modules can fill in if needed? Presently, bsd_comp.c and ppp_deflate.c don't need these, so they will be filled with zeros automatically at struct compressor instantiation. This hunk may still be contriversial though. It adds a negative return value to the compress() method, which is only (presently) used by ppp_mppe (bsd_comp.c and ppp_deflate.c always return 0 if they couldn't compress), to indicate the frame should be dropped. - } else { + } else if (len =3D=3D 0) { /* didn't compress, or CCP not up yet */ kfree_skb(new_skb); + } else { + /* + * (len < 0) + * MPPE requires that we do not send unencrypted + * frames. The compressor will return -1 if we + * should drop the frame. We cannot simply test + * the compress_proto because MPPE and MPPC share + * the same number. + */ + printk(KERN_ERR "ppp: compressor dropped pkt\n"); + kfree_skb(new_skb); + goto drop; Thoughts? Patch below against 2.6.7-bk ppp_generic.c and ppp-comp.h to add such, for comment only. Thanks, Matt --=20 Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com =3D=3D=3D=3D=3D drivers/net/ppp_generic.c 1.45 vs edited =3D=3D=3D=3D=3D --- 1.45/drivers/net/ppp_generic.c 2004-04-09 18:21:06 -05:00 +++ edited/drivers/net/ppp_generic.c 2004-06-21 10:56:34 -05:00 @@ -1066,8 +1066,9 @@ /* try to do packet compression */ if ((ppp->xstate & SC_COMP_RUN) && ppp->xc_state !=3D 0 && proto !=3D PPP_LCP && proto !=3D PPP_CCP) { - new_skb =3D alloc_skb(ppp->dev->mtu + ppp->dev->hard_header_len, - GFP_ATOMIC); + int new_skb_size =3D ppp->dev->mtu + ppp->xcomp->comp_skb_= extra_space + ppp->dev->hard_header_len; + int compressor_skb_size =3D ppp->dev->mtu + ppp->xcomp->co= mp_skb_extra_space + PPP_HDRLEN; + new_skb =3D alloc_skb(new_skb_size, GFP_ATOMIC); if (new_skb =3D=3D 0) { printk(KERN_ERR "PPP: no memory (comp pkt)\n"); goto drop; @@ -1079,15 +1080,27 @@ /* compressor still expects A/C bytes in hdr */ len =3D ppp->xcomp->compress(ppp->xc_state, skb->data - 2, new_skb->data, skb->len + 2, - ppp->dev->mtu + PPP_HDRLEN); + compressor_skb_size); if (len > 0 && (ppp->flags & SC_CCP_UP)) { kfree_skb(skb); skb =3D new_skb; skb_put(skb, len); skb_pull(skb, 2); /* pull off A/C bytes */ - } else { + } else if (len =3D=3D 0) { /* didn't compress, or CCP not up yet */ kfree_skb(new_skb); + } else { + /* + * (len < 0) + * MPPE requires that we do not send unencrypted + * frames. The compressor will return -1 if we + * should drop the frame. We cannot simply test + * the compress_proto because MPPE and MPPC share + * the same number. + */ + printk(KERN_ERR "ppp: compressor dropped pkt\n"); + kfree_skb(new_skb); + goto drop; } } =20 @@ -1596,7 +1609,7 @@ goto err; =20 if (proto =3D=3D PPP_COMP) { - ns =3D dev_alloc_skb(ppp->mru + PPP_HDRLEN); + ns =3D dev_alloc_skb(ppp->mru + ppp->rcomp->decomp_skb_extra_space + PPP= _HDRLEN); if (ns =3D=3D 0) { printk(KERN_ERR "ppp_decompress_frame: no memory\n"); goto err; =3D=3D=3D=3D=3D include/linux/ppp-comp.h 1.4 vs edited =3D=3D=3D=3D=3D --- 1.4/include/linux/ppp-comp.h 2003-08-07 18:57:19 -05:00 +++ edited/include/linux/ppp-comp.h 2004-06-21 10:59:44 -05:00 @@ -111,6 +111,10 @@ =20 /* Used in locking compressor modules */ struct module *owner; + /* Extra skb space needed by the compressor algorithm */ + unsigned int comp_skb_extra_space; + /* Extra skb space needed by the decompressor algorithm */ + unsigned int decomp_skb_extra_space; }; =20 /* --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA1w84Iavu95Lw/AkRAr1mAJ4u3/jwEeEaNuNzjNPTa2hDyGi3EgCglS9E WvLLynOS2WwhGYha+5ysAA0= =0xay -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From davem@redhat.com Mon Jun 21 09:39:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 09:39:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LGddgi020310 for ; Mon, 21 Jun 2004 09:39:40 -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 i5LGdbe1030594; Mon, 21 Jun 2004 12:39:37 -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 i5LGdb019271; Mon, 21 Jun 2004 12:39:37 -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 i5LGdGBe018329; Mon, 21 Jun 2004 12:39:17 -0400 Date: Mon, 21 Jun 2004 09:39:18 -0700 From: "David S. Miller" To: Andrew Morton Cc: netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [NET]: Lockless loopback patch (version 2). Message-Id: <20040621093918.61b43aad.davem@redhat.com> In-Reply-To: <20040621035702.6114bdbe.akpm@osdl.org> References: <200406210510.i5L5A340018849@hera.kernel.org> <20040621035702.6114bdbe.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: 6206 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 Mon, 21 Jun 2004 03:57:02 -0700 Andrew Morton wrote: > Still, I don't see why we need to use alloc_percpu() - why not > statically allocate it? > > This compiles, but does need runtime testing. Looks good to me, applied. From tharbaugh@lnxi.com Mon Jun 21 09:55:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 09:55:32 -0700 (PDT) Received: from ash.lnxi.com (208.177.141.226.ptr.us.xo.net [208.177.141.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LGtUgi021109 for ; Mon, 21 Jun 2004 09:55:30 -0700 Received: (qmail 20149 invoked from network); 21 Jun 2004 16:59:47 -0000 Received: from tubarao.lnxi.com (HELO ?192.168.15.106?) (192.168.15.106) by ash.lnxi.com with SMTP; 21 Jun 2004 16:59:47 -0000 Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler From: Thayne Harbaugh Reply-To: tharbaugh@lnxi.com To: David Greaves Cc: Jens Laas , Stephen Hemminger , netdev@oss.sgi.com, ganesh.venkatesan@intel.com In-Reply-To: <40D2B114.5020201@dgreaves.com> References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> <40D2B114.5020201@dgreaves.com> Content-Type: text/plain Organization: Linux Networx Message-Id: <1087836178.20902.23.camel@tubarao> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 21 Jun 2004 10:42:58 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 6208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tharbaugh@lnxi.com Precedence: bulk X-list: netdev On Fri, 2004-06-18 at 03:08, David Greaves wrote: > Jens Laas wrote: > > We have tried different versions of e1000 without luck. > > Me too, 3 cards. > (did I mention I have 2 machines with very similar specs (AMD/VIAKT600) > and the other one works - actually, to be accurate, hasn't yet failed > but hasn't yet run at full speed - and it has a higher CPU speed) What do you mean by, ". . . hasn't yet run at full speed - and it has a higher CPU speed . . ." ? Does this mean that you can't get the card to have a reasonable throughput (~900Mbps)? -- Thayne Harbaugh Linux Networx From max@stro.at Mon Jun 21 10:18:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 10:18:34 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LHIVgi022019 for ; Mon, 21 Jun 2004 10:18:31 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 3ED665C0D4 for ; Mon, 21 Jun 2004 19:18: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 04474-10 for ; Mon, 21 Jun 2004 19:18:29 +0200 (CEST) Received: from sputnik (unknown [62.47.144.54]) by baikonur.stro.at (Postfix) with ESMTP id 7A8DC5C002 for ; Mon, 21 Jun 2004 19:18:29 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1BcSRE-0003n5-Nw for netdev@oss.sgi.com; Mon, 21 Jun 2004 19:18:32 +0200 Date: Mon, 21 Jun 2004 19:18:32 +0200 From: maximilian attems To: netdev@oss.sgi.com Subject: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create() Message-ID: <20040621171832.GE1545@sputnik.stro.at> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 6209 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 From: Francois Romieu kmem_cache_create leak. Note: fib_hash_init() can be called many times. Signed-off-by: Maximilian Attems --- linux-2.6.7-max/net/ipv4/fib_hash.c | 19 ++++++++++++++----- 1 files changed, 14 insertions(+), 5 deletions(-) diff -puN net/ipv4/fib_hash.c~ipv4_fib_hash_check net/ipv4/fib_hash.c --- linux-2.6.7/net/ipv4/fib_hash.c~ipv4_fib_hash_check 2004-06-18 09:10:27.000000000 +0200 +++ linux-2.6.7-max/net/ipv4/fib_hash.c 2004-06-18 09:10:27.000000000 +0200 @@ -871,15 +871,18 @@ struct fib_table * __init fib_hash_init( { struct fib_table *tb; - if (fn_hash_kmem == NULL) + tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL); + if (!tb) + goto err_out; + + if (!fn_hash_kmem) { fn_hash_kmem = kmem_cache_create("ip_fib_hash", sizeof(struct fib_node), 0, SLAB_HWCACHE_ALIGN, NULL, NULL); - - tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL); - if (tb == NULL) - return NULL; + if (!fn_hash_kmem) + goto err_free; + } tb->tb_id = id; tb->tb_lookup = fn_hash_lookup; @@ -889,7 +892,13 @@ struct fib_table * __init fib_hash_init( tb->tb_select_default = fn_hash_select_default; tb->tb_dump = fn_hash_dump; memset(tb->tb_data, 0, sizeof(struct fn_hash)); +err_out: return tb; + +err_free: + kfree(tb); + tb = NULL; + goto err_out; } /* ------------------------------------------------------------------------ */ _ From david@dgreaves.com Mon Jun 21 10:29:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 10:29:34 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LHTUgi022797 for ; Mon, 21 Jun 2004 10:29:30 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 54071E6D3B; Mon, 21 Jun 2004 18:28:39 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17772-02; Mon, 21 Jun 2004 18:28:39 +0100 (BST) Received: from oak.dgreaves.com (modem-3418.putangitangi.dialup.pol.co.uk [81.78.205.90]) by mail.ukfsn.org (Postfix) with ESMTP id 14F5BE6A83; Mon, 21 Jun 2004 18:28:38 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.66]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BcSdl-0001vS-2W; Mon, 21 Jun 2004 18:31:29 +0100 Message-ID: <40D71AEF.8030006@dgreaves.com> Date: Mon, 21 Jun 2004 18:29:19 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tharbaugh@lnxi.com Cc: Jens Laas , Stephen Hemminger , netdev@oss.sgi.com, ganesh.venkatesan@intel.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler References: <40CDD68C.8070509@dgreaves.com> <20040615155111.26d6b809@dell_ss3.pdx.osdl.net> <40D0280B.2030308@dgreaves.com> <40D2B114.5020201@dgreaves.com> <1087836178.20902.23.camel@tubarao> In-Reply-To: <1087836178.20902.23.camel@tubarao> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev Thayne Harbaugh wrote: >On Fri, 2004-06-18 at 03:08, David Greaves wrote: > > > >>Jens Laas wrote: >> >> >>>We have tried different versions of e1000 without luck. >>> >>> >>Me too, 3 cards. >>(did I mention I have 2 machines with very similar specs (AMD/VIAKT600) >>and the other one works - actually, to be accurate, hasn't yet failed >>but hasn't yet run at full speed - and it has a higher CPU speed) >> >> > >What do you mean by, ". . . hasn't yet run at full speed - and it has a >higher CPU speed . . ." ? Does this mean that you can't get the card to >have a reasonable throughput (~900Mbps)? > > > It sounded reasonable when I wrote it :) I have 2 machines I can easily test with (wired back to back) Machine 1 has an AMD3000+ CPU, machine 2 has an AMD3200+ cpu (maybe not relevant - maybe important if it's timing related?) Machine one stalls within a few kb. Machine two has shown no signs of failure yet. However the other machine has not been stressed at all so it has 'not yet run at full speed' - not surprising since it has no friends with working gigabit cards :) David PS I tried some experiments this weekend with a third machine but I got nasty kernel oopses on the second (supposedly good) whenever I did ifconfig eth1 mtu 9000 and I've not had time to get any proper results or a minimal failure yet. simply issuing ifconfig eth1 mtu 9000 on the second machine gave me this: Jun 18 16:33:08 haze kernel: printk: 1 messages suppressed. Jun 18 16:33:08 haze kernel: ifconfig: page allocation failure. order:3, mode:0x20 Jun 18 16:33:08 haze kernel: [__alloc_pages+728/848] __alloc_pages+0x2d8/0x350 Jun 18 16:33:08 haze kernel: [__get_free_pages+37/64] __get_free_pages+0x25/0x40 Jun 18 16:33:08 haze kernel: [kmem_getpages+32/176] kmem_getpages+0x20/0xb0 Jun 18 16:33:08 haze kernel: [cache_grow+166/512] cache_grow+0xa6/0x200 Jun 18 16:33:08 haze kernel: [cache_alloc_refill+342/544] cache_alloc_refill+0x156/0x220 Jun 18 16:33:08 haze kernel: [__kmalloc+116/128] __kmalloc+0x74/0x80 ... I'll report more fully when I can produce something consistent. From max@stro.at Mon Jun 21 10:43:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 10:43:56 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LHhfgi023319 for ; Mon, 21 Jun 2004 10:43:44 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 3ABBA5C0A4 for ; Mon, 21 Jun 2004 19:09: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 27908-07 for ; Mon, 21 Jun 2004 19:09:01 +0200 (CEST) Received: from sputnik (unknown [62.47.144.54]) by baikonur.stro.at (Postfix) with ESMTP id 88D905C002 for ; Mon, 21 Jun 2004 19:09:01 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1BcSI4-0003Pr-VA for netdev@oss.sgi.com; Mon, 21 Jun 2004 19:09:05 +0200 Date: Mon, 21 Jun 2004 19:09:04 +0200 From: maximilian attems To: netdev@oss.sgi.com Subject: [patch-kj] net/econet/af_econet.c fix warning xyz never used Message-ID: <20040621170904.GD1545@sputnik.stro.at> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 6211 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 From: (Walter Harms) moving the define a bit higher removes two useless warnings. regards, walter Signed-off-by: Maximilian Attems --- linux-2.6.7-max/net/econet/af_econet.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/econet/af_econet.c~fix-warning-af_econet net/econet/af_econet.c --- linux-2.6.7/net/econet/af_econet.c~fix-warning-af_econet 2004-06-18 10:20:06.000000000 +0200 +++ linux-2.6.7-max/net/econet/af_econet.c 2004-06-18 10:20:06.000000000 +0200 @@ -255,9 +255,9 @@ static int econet_sendmsg(struct kiocb * struct ec_addr addr; int err; unsigned char port, cb; +#ifdef CONFIG_ECONET_NATIVE struct sk_buff *skb; struct ec_cb *eb; -#ifdef CONFIG_ECONET_NATIVE unsigned short proto = 0; #endif #ifdef CONFIG_ECONET_AUNUDP From yoshfuji@wide.ad.jp Mon Jun 21 10:50:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 10:50:42 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LHodgi024690 for ; Mon, 21 Jun 2004 10:50:39 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 22A1433CE5; Tue, 22 Jun 2004 02:51:41 +0900 (JST) Date: Tue, 22 Jun 2004 02:51:38 +0900 (JST) Message-Id: <20040622.025138.33683810.yoshfuji@wide.ad.jp> To: janitor@sternwelten.at Cc: netdev@oss.sgi.com Subject: Re: [patch-kj] net/econet/af_econet.c fix warning xyz never used From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040621170904.GD1545@sputnik.stro.at> References: <20040621170904.GD1545@sputnik.stro.at> X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc 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: 6212 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 In article <20040621170904.GD1545@sputnik.stro.at> (at Mon, 21 Jun 2004 19:09:04 +0200), maximilian attems says: > From: (Walter Harms) > moving the define a bit higher removes two useless warnings. : > Signed-off-by: Maximilian Attems : > unsigned char port, cb; > +#ifdef CONFIG_ECONET_NATIVE > struct sk_buff *skb; > struct ec_cb *eb; > -#ifdef CONFIG_ECONET_NATIVE > unsigned short proto = 0; Already fixed in current bk tree. Thanks. --yoshfuji From ganesh.venkatesan@intel.com Mon Jun 21 10:59:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 10:59:20 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LHxHgi025188 for ; Mon, 21 Jun 2004 10:59:18 -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 i5LHwWpF024725; Mon, 21 Jun 2004 17:58: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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5LHxiJ3030579; Mon, 21 Jun 2004 17:59:52 GMT Received: from [134.134.3.106] ([134.134.3.106]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062110584204631 ; Mon, 21 Jun 2004 10:58:43 -0700 Date: Mon, 21 Jun 2004 10:43:58 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@localhost.localdomain Reply-To: ganesh.venkatesan@intel.com To: David Greaves cc: tharbaugh@lnxi.com, Jens Laas , Stephen Hemminger , , "Venkatesan, Ganesh" Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler In-Reply-To: <40D71AEF.8030006@dgreaves.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 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 i5LHxHgi025188 X-archive-position: 6213 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 David: Could you try the following patch to workaround the meemory allocation issue you are reporting? --------------------- --- e1000_main.c 2004-06-21 10:37:29.496090824 -0700 +++ e1000_main.c-patched 2004-06-21 10:37:06.920522832 -0700 @@ -796,7 +796,7 @@ e1000_setup_tx_resources(struct e1000_ad int size; size = sizeof(struct e1000_buffer) * txdr->count; - txdr->buffer_info = kmalloc(size, GFP_KERNEL); + txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { return -ENOMEM; } @@ -809,7 +809,7 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { - kfree(txdr->buffer_info); + vfree(txdr->buffer_info); return -ENOMEM; } memset(txdr->desc, 0, txdr->size); @@ -913,7 +913,7 @@ e1000_setup_rx_resources(struct e1000_ad int size; size = sizeof(struct e1000_buffer) * rxdr->count; - rxdr->buffer_info = kmalloc(size, GFP_KERNEL); + rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { return -ENOMEM; } @@ -927,7 +927,7 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { - kfree(rxdr->buffer_info); + vfree(rxdr->buffer_info); return -ENOMEM; } memset(rxdr->desc, 0, rxdr->size); @@ -1051,7 +1051,7 @@ e1000_free_tx_resources(struct e1000_ada e1000_clean_tx_ring(adapter); - kfree(adapter->tx_ring.buffer_info); + vfree(adapter->tx_ring.buffer_info); adapter->tx_ring.buffer_info = NULL; pci_free_consistent(pdev, adapter->tx_ring.size, @@ -1120,7 +1120,7 @@ e1000_free_rx_resources(struct e1000_ada e1000_clean_rx_ring(adapter); - kfree(rx_ring->buffer_info); + vfree(rx_ring->buffer_info); rx_ring->buffer_info = NULL; pci_free_consistent(pdev, rx_ring->size, rx_ring->desc, rx_ring->dma); --- e1000.h 2004-06-21 10:37:29.523086720 -0700 +++ e1000.h-patched 2004-06-21 10:37:15.506217608 -0700 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include #include @@ -159,9 +160,9 @@ struct e1000_adapter; struct e1000_buffer { struct sk_buff *skb; uint64_t dma; - unsigned long length; unsigned long time_stamp; - unsigned int next_to_watch; + uint16_t next_to_watch; + uint16_t length; }; struct e1000_desc_ring { ---------------------- ganesh. On Mon, 21 Jun 2004, David Greaves wrote: > > Thayne Harbaugh wrote: > > >On Fri, 2004-06-18 at 03:08, David Greaves wrote: > > > > > > > >>Jens Laas wrote: > >> > >> > >>>We have tried different versions of e1000 without luck. > >>> > >>> > >>Me too, 3 cards. > >>(did I mention I have 2 machines with very similar specs (AMD/VIAKT600) > >>and the other one works - actually, to be accurate, hasn't yet failed > >>but hasn't yet run at full speed - and it has a higher CPU speed) > >> > >> > > > >What do you mean by, ". . . hasn't yet run at full speed - and it has a > >higher CPU speed . . ." ? Does this mean that you can't get the card to > >have a reasonable throughput (~900Mbps)? > > > > > > > > It sounded reasonable when I wrote it :) > > I have 2 machines I can easily test with (wired back to back) > Machine 1 has an AMD3000+ CPU, machine 2 has an AMD3200+ cpu (maybe not > relevant - maybe important if it's timing related?) > > Machine one stalls within a few kb. > Machine two has shown no signs of failure yet. > > However the other machine has not been stressed at all so it has 'not > yet run at full speed' - not surprising since it has no friends with > working gigabit cards :) > > David > PS > I tried some experiments this weekend with a third machine but I got > nasty kernel oopses on the second (supposedly good) whenever I did > ifconfig eth1 mtu 9000 and I've not had time to get any proper results > or a minimal failure yet. > > simply issuing > ifconfig eth1 mtu 9000 > on the second machine gave me this: > > Jun 18 16:33:08 haze kernel: printk: 1 messages suppressed. > Jun 18 16:33:08 haze kernel: ifconfig: page allocation failure. order:3, > mode:0x20 > Jun 18 16:33:08 haze kernel: [__alloc_pages+728/848] > __alloc_pages+0x2d8/0x350 > Jun 18 16:33:08 haze kernel: [__get_free_pages+37/64] > __get_free_pages+0x25/0x40 > Jun 18 16:33:08 haze kernel: [kmem_getpages+32/176] kmem_getpages+0x20/0xb0 > Jun 18 16:33:08 haze kernel: [cache_grow+166/512] cache_grow+0xa6/0x200 > Jun 18 16:33:08 haze kernel: [cache_alloc_refill+342/544] > cache_alloc_refill+0x156/0x220 > Jun 18 16:33:08 haze kernel: [__kmalloc+116/128] __kmalloc+0x74/0x80 > ... > > I'll report more fully when I can produce something consistent. > > > From yoshfuji@linux-ipv6.org Mon Jun 21 11:20:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 11:20:39 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LIKagi026665 for ; Mon, 21 Jun 2004 11:20:36 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 523F033CE5; Tue, 22 Jun 2004 03:21:38 +0900 (JST) Date: Tue, 22 Jun 2004 03:21:38 +0900 (JST) Message-Id: <20040622.032138.58652005.yoshfuji@linux-ipv6.org> To: romieu@fr.zoreil.com, janitor@sternwelten.at Cc: netdev@oss.sgi.com Subject: Re: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040621171832.GE1545@sputnik.stro.at> References: <20040621171832.GE1545@sputnik.stro.at> 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: 6214 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 <20040621171832.GE1545@sputnik.stro.at> (at Mon, 21 Jun 2004 19:18:32 +0200), maximilian attems says: > From: Francois Romieu > > kmem_cache_create leak. > > Note: fib_hash_init() can be called many times. > > Signed-off-by: Maximilian Attems Please tell us what kind of leakage do you see? Is it just enough to return NULL if kmem_cache_create() fails like this? --- a/net/ipv4/fib_hash.c 10 Nov 2003 23:40:57 -0000 1.1.1.13 +++ b/net/ipv4/fib_hash.c 21 Jun 2004 18:19:16 -0000 @@ -871,12 +871,14 @@ { struct fib_table *tb; - if (fn_hash_kmem == NULL) + if (fn_hash_kmem == NULL) { fn_hash_kmem = kmem_cache_create("ip_fib_hash", sizeof(struct fib_node), 0, SLAB_HWCACHE_ALIGN, NULL, NULL); - + if (fn_hash_kmem == NULL) + return NULL; + } tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL); if (tb == NULL) return NULL; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From david@dgreaves.com Mon Jun 21 11:35:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 11:35:11 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LIZ5gi027222 for ; Mon, 21 Jun 2004 11:35:06 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 9E5C5E6D44; Mon, 21 Jun 2004 19:34:11 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19392-16; Mon, 21 Jun 2004 19:34:11 +0100 (BST) Received: from oak.dgreaves.com (modem-3418.putangitangi.dialup.pol.co.uk [81.78.205.90]) by mail.ukfsn.org (Postfix) with ESMTP id E6153E6D3F; Mon, 21 Jun 2004 19:34:08 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.66]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BcTfA-000211-EP; Mon, 21 Jun 2004 19:37:00 +0100 Message-ID: <40D72A4A.2080007@dgreaves.com> Date: Mon, 21 Jun 2004 19:34:50 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ganesh.venkatesan@intel.com Cc: tharbaugh@lnxi.com, Jens Laas , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delay scheduler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev OK applied patch ifdown eth1; modprobe -r e1000;modprobe e1000;ifup eth1; ifconfig eth1 mtu 9000 (so no reboot) dmesg: e1000: Ignoring new-style parameters in presence of obsolete ones Intel(R) PRO/1000 Network Driver - version 5.2.52-k4 Copyright (c) 1999-2004 Intel Corporation. e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex ifconfig: page allocation failure. order:3, mode:0x20 [] __alloc_pages+0x2d8/0x350 [] __get_free_pages+0x25/0x40 [] kmem_getpages+0x20/0xb0 [] cache_grow+0xa6/0x200 [] cache_alloc_refill+0x156/0x220 [] __kmalloc+0x74/0x80 [] alloc_skb+0x47/0xe0 [] e1000_alloc_rx_buffers+0x62/0x100 [e1000] [] e1000_up+0x45/0xb0 [e1000] [] e1000_change_mtu+0x7c/0x110 [e1000] [] dev_set_mtu+0x79/0x90 [] dev_ioctl+0x1f5/0x280 [] inet_ioctl+0x8e/0xa0 [] sock_ioctl+0xe9/0x290 [] sys_ioctl+0xef/0x260 [] do_page_fault+0x0/0x4da [] syscall_call+0x7/0xb ifconfig: page allocation failure. order:3, mode:0x20 [] __alloc_pages+0x2d8/0x350 [] __get_free_pages+0x25/0x40 [] kmem_getpages+0x20/0xb0 [] cache_grow+0xa6/0x200 [] cache_alloc_refill+0x156/0x220 [] wake_up_state+0x1a/0x20 [] __kmalloc+0x74/0x80 [] alloc_skb+0x47/0xe0 [] e1000_alloc_rx_buffers+0x62/0x100 [e1000] [] e1000_clean_rx_irq+0xf7/0x450 [e1000] [] recalc_task_prio+0x8f/0x190 [] e1000_clean+0x43/0xc0 [e1000] [] net_rx_action+0x6a/0xf0 [] __do_softirq+0x7d/0x80 [] do_softirq+0x26/0x30 [] do_IRQ+0xfd/0x130 [] common_interrupt+0x18/0x20 [] e1000_irq_enable+0x27/0x30 [e1000] [] e1000_up+0x9d/0xb0 [e1000] [] e1000_change_mtu+0x7c/0x110 [e1000] [] dev_set_mtu+0x79/0x90 [] dev_ioctl+0x1f5/0x280 [] inet_ioctl+0x8e/0xa0 [] sock_ioctl+0xe9/0x290 [] sys_ioctl+0xef/0x260 [] do_page_fault+0x0/0x4da [] syscall_call+0x7/0xb kdeinit: page allocation failure. order:3, mode:0x20 [] __alloc_pages+0x2d8/0x350 [] __get_free_pages+0x25/0x40 [] kmem_getpages+0x20/0xb0 [] cache_grow+0xa6/0x200 [] cache_alloc_refill+0x156/0x220 [] __kmalloc+0x74/0x80 [] alloc_skb+0x47/0xe0 [] e1000_alloc_rx_buffers+0x62/0x100 [e1000] [] e1000_clean_rx_irq+0xf7/0x450 [e1000] [] e1000_clean+0x43/0xc0 [e1000] [] net_rx_action+0x6a/0xf0 [] __do_softirq+0x7d/0x80 [] do_softirq+0x26/0x30 [] do_IRQ+0xfd/0x130 [] common_interrupt+0x18/0x20 ... David ganesh.venkatesan@intel.com wrote: >David: > >Could you try the following patch to workaround the meemory allocation >issue you are reporting? > >--------------------- >--- e1000_main.c 2004-06-21 10:37:29.496090824 -0700 >+++ e1000_main.c-patched 2004-06-21 10:37:06.920522832 -0700 >@@ -796,7 +796,7 @@ e1000_setup_tx_resources(struct e1000_ad > int size; > > size = sizeof(struct e1000_buffer) * txdr->count; >- txdr->buffer_info = kmalloc(size, GFP_KERNEL); >+ txdr->buffer_info = vmalloc(size); > if(!txdr->buffer_info) { > return -ENOMEM; > } >@@ -809,7 +809,7 @@ e1000_setup_tx_resources(struct e1000_ad > > txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); > if(!txdr->desc) { >- kfree(txdr->buffer_info); >+ vfree(txdr->buffer_info); > return -ENOMEM; > } > memset(txdr->desc, 0, txdr->size); >@@ -913,7 +913,7 @@ e1000_setup_rx_resources(struct e1000_ad > int size; > > size = sizeof(struct e1000_buffer) * rxdr->count; >- rxdr->buffer_info = kmalloc(size, GFP_KERNEL); >+ rxdr->buffer_info = vmalloc(size); > if(!rxdr->buffer_info) { > return -ENOMEM; > } >@@ -927,7 +927,7 @@ e1000_setup_rx_resources(struct e1000_ad > rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); > > if(!rxdr->desc) { >- kfree(rxdr->buffer_info); >+ vfree(rxdr->buffer_info); > return -ENOMEM; > } > memset(rxdr->desc, 0, rxdr->size); >@@ -1051,7 +1051,7 @@ e1000_free_tx_resources(struct e1000_ada > > e1000_clean_tx_ring(adapter); > >- kfree(adapter->tx_ring.buffer_info); >+ vfree(adapter->tx_ring.buffer_info); > adapter->tx_ring.buffer_info = NULL; > > pci_free_consistent(pdev, adapter->tx_ring.size, >@@ -1120,7 +1120,7 @@ e1000_free_rx_resources(struct e1000_ada > > e1000_clean_rx_ring(adapter); > >- kfree(rx_ring->buffer_info); >+ vfree(rx_ring->buffer_info); > rx_ring->buffer_info = NULL; > > pci_free_consistent(pdev, rx_ring->size, rx_ring->desc, rx_ring->dma); >--- e1000.h 2004-06-21 10:37:29.523086720 -0700 >+++ e1000.h-patched 2004-06-21 10:37:15.506217608 -0700 >@@ -49,6 +49,7 @@ > #include > #include > #include >+#include > #include > #include > #include >@@ -159,9 +160,9 @@ struct e1000_adapter; > struct e1000_buffer { > struct sk_buff *skb; > uint64_t dma; >- unsigned long length; > unsigned long time_stamp; >- unsigned int next_to_watch; >+ uint16_t next_to_watch; >+ uint16_t length; > }; > > struct e1000_desc_ring { >---------------------- >ganesh. > >On Mon, 21 Jun 2004, David Greaves wrote: > > > >>Thayne Harbaugh wrote: >> >> >> >>>On Fri, 2004-06-18 at 03:08, David Greaves wrote: >>> >>> >>> >>> >>> >>>>Jens Laas wrote: >>>> >>>> >>>> >>>> >>>>>We have tried different versions of e1000 without luck. >>>>> >>>>> >>>>> >>>>> >>>>Me too, 3 cards. >>>>(did I mention I have 2 machines with very similar specs (AMD/VIAKT600) >>>>and the other one works - actually, to be accurate, hasn't yet failed >>>>but hasn't yet run at full speed - and it has a higher CPU speed) >>>> >>>> >>>> >>>> >>>What do you mean by, ". . . hasn't yet run at full speed - and it has a >>>higher CPU speed . . ." ? Does this mean that you can't get the card to >>>have a reasonable throughput (~900Mbps)? >>> >>> >>> >>> >>> >>It sounded reasonable when I wrote it :) >> >>I have 2 machines I can easily test with (wired back to back) >>Machine 1 has an AMD3000+ CPU, machine 2 has an AMD3200+ cpu (maybe not >>relevant - maybe important if it's timing related?) >> >>Machine one stalls within a few kb. >>Machine two has shown no signs of failure yet. >> >>However the other machine has not been stressed at all so it has 'not >>yet run at full speed' - not surprising since it has no friends with >>working gigabit cards :) >> >>David >>PS >>I tried some experiments this weekend with a third machine but I got >>nasty kernel oopses on the second (supposedly good) whenever I did >>ifconfig eth1 mtu 9000 and I've not had time to get any proper results >>or a minimal failure yet. >> >>simply issuing >>ifconfig eth1 mtu 9000 >>on the second machine gave me this: >> >>Jun 18 16:33:08 haze kernel: printk: 1 messages suppressed. >>Jun 18 16:33:08 haze kernel: ifconfig: page allocation failure. order:3, >>mode:0x20 >>Jun 18 16:33:08 haze kernel: [__alloc_pages+728/848] >>__alloc_pages+0x2d8/0x350 >>Jun 18 16:33:08 haze kernel: [__get_free_pages+37/64] >>__get_free_pages+0x25/0x40 >>Jun 18 16:33:08 haze kernel: [kmem_getpages+32/176] kmem_getpages+0x20/0xb0 >>Jun 18 16:33:08 haze kernel: [cache_grow+166/512] cache_grow+0xa6/0x200 >>Jun 18 16:33:08 haze kernel: [cache_alloc_refill+342/544] >>cache_alloc_refill+0x156/0x220 >>Jun 18 16:33:08 haze kernel: [__kmalloc+116/128] __kmalloc+0x74/0x80 >>... >> >>I'll report more fully when I can produce something consistent. >> >> >> >> >> > > > > From max@stro.at Mon Jun 21 11:51:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 11:51:39 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LIpYgi027785 for ; Mon, 21 Jun 2004 11:51:35 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 8F1F55C0A4; Mon, 21 Jun 2004 20:51: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 09746-03; Mon, 21 Jun 2004 20:51:32 +0200 (CEST) Received: from sputnik (unknown [62.47.155.15]) by baikonur.stro.at (Postfix) with ESMTP id 5CB855C002; Mon, 21 Jun 2004 20:51:32 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1BcTtH-0004s6-KP; Mon, 21 Jun 2004 20:51:36 +0200 Date: Mon, 21 Jun 2004 20:51:35 +0200 From: maximilian attems To: saw@saw.sw.com.sg Cc: netdev@oss.sgi.com Subject: [patch-kj] remove old ifdef'd code from eepro100.c Message-ID: <20040621185135.GA1545@sputnik.stro.at> Mail-Followup-To: saw@saw.sw.com.sg, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 6216 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 From: Domen Puncer Patches to remove some old ifdefs. remove unused #include Signed-off-by: Maximilian Attems --- linux-2.6.7-max/drivers/net/eepro100.c | 17 ----------------- 1 files changed, 17 deletions(-) diff -puN drivers/net/eepro100.c~remove-old-ifdefs-eepro100 drivers/net/eepro100.c --- linux-2.6.7/drivers/net/eepro100.c~remove-old-ifdefs-eepro100 2004-06-18 09:15:04.000000000 +0200 +++ linux-2.6.7-max/drivers/net/eepro100.c 2004-06-18 09:15:04.000000000 +0200 @@ -94,7 +94,6 @@ static int options[] = {-1, -1, -1, -1, #endif #include -#include #include #include @@ -2453,22 +2452,6 @@ static struct pci_driver eepro100_driver #endif /* CONFIG_PM */ }; -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,48) -static int pci_module_init(struct pci_driver *pdev) -{ - int rc; - - rc = pci_register_driver(pdev); - if (rc <= 0) { - printk(KERN_INFO "%s: No cards found, driver not installed.\n", - pdev->name); - pci_unregister_driver(pdev); - return -ENODEV; - } - return 0; -} -#endif - static int __init eepro100_init_module(void) { #ifdef MODULE _ From jgarzik@pobox.com Mon Jun 21 12:22:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 12:22:30 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LJMRgi031854 for ; Mon, 21 Jun 2004 12:22:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bbn4E-0002Nm-Ky; Sat, 19 Jun 2004 22:08:02 +0100 Message-ID: <40D4AB26.1080009@pobox.com> Date: Sat, 19 Jun 2004 17:07:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeb Cramer CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/1 2.6] e1000 management reset fix References: <1087361013.12233.14.camel@mini> In-Reply-To: <1087361013.12233.14.camel@mini> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6217 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 From max@stro.at Mon Jun 21 13:04:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 13:04:23 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LK4Kgi001287 for ; Mon, 21 Jun 2004 13:04:20 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 4CAE75C135; Mon, 21 Jun 2004 22:04:19 +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 21982-09; Mon, 21 Jun 2004 22:04:17 +0200 (CEST) Received: from sputnik (unknown [62.47.155.15]) by baikonur.stro.at (Postfix) with ESMTP id 80B6E5C002; Mon, 21 Jun 2004 22:04:17 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1BcV1g-0005sb-Qz; Mon, 21 Jun 2004 22:04:21 +0200 Date: Mon, 21 Jun 2004 22:04:20 +0200 From: maximilian attems To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: romieu@fr.zoreil.com, janitor@sternwelten.at, netdev@oss.sgi.com Subject: Re: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create() Message-ID: <20040621200420.GI1545@sputnik.stro.at> Mail-Followup-To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , romieu@fr.zoreil.com, janitor@sternwelten.at, netdev@oss.sgi.com References: <20040621171832.GE1545@sputnik.stro.at> <20040622.032138.58652005.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040622.032138.58652005.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 6218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: max@stro.at Precedence: bulk X-list: netdev On Tue, 22 Jun 2004, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <20040621171832.GE1545@sputnik.stro.at> (at Mon, 21 Jun 2004 19:18:32 +0200), maximilian attems says: > > > From: Francois Romieu > > > > kmem_cache_create leak. > > > > Note: fib_hash_init() can be called many times. > > > > Signed-off-by: Maximilian Attems > > Please tell us what kind of leakage do you see? > Is it just enough to return NULL if kmem_cache_create() fails > like this? > > --- a/net/ipv4/fib_hash.c 10 Nov 2003 23:40:57 -0000 1.1.1.13 > +++ b/net/ipv4/fib_hash.c 21 Jun 2004 18:19:16 -0000 > @@ -871,12 +871,14 @@ > { > struct fib_table *tb; > > - if (fn_hash_kmem == NULL) > + if (fn_hash_kmem == NULL) { > fn_hash_kmem = kmem_cache_create("ip_fib_hash", > sizeof(struct fib_node), > 0, SLAB_HWCACHE_ALIGN, > NULL, NULL); > - > + if (fn_hash_kmem == NULL) > + return NULL; > + } > tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL); > if (tb == NULL) > return NULL; doesn't seem to be enough, because if (tb == NULL) fn_hash_kmem won't be freed, or am i overseeing something? a++ maks From max@stro.at Mon Jun 21 13:13:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 13:13:56 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LKDggi002647 for ; Mon, 21 Jun 2004 13:13:43 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id F36935C0A4 for ; Mon, 21 Jun 2004 21:42:37 +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 07808-02 for ; Mon, 21 Jun 2004 21:42:37 +0200 (CEST) Received: from sputnik (unknown [62.47.155.15]) by baikonur.stro.at (Postfix) with ESMTP id 577F85C002 for ; Mon, 21 Jun 2004 21:42:37 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1BcUgj-0005jo-0v for netdev@oss.sgi.com; Mon, 21 Jun 2004 21:42:41 +0200 Date: Mon, 21 Jun 2004 21:42:40 +0200 From: maximilian attems To: netdev@oss.sgi.com Subject: [patch-kj] remove old ifdef'd code from hamradio/dmascc.c Message-ID: <20040621194240.GF1545@sputnik.stro.at> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 6219 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 From: Domen Puncer remove unused #include didn't find maintainer of hamradio, hope it will get picked up. Signed-off-by: Maximilian Attems --- linux-2.6.7-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.7/drivers/net/hamradio/dmascc.c~remove-old-ifdefs-dmascc 2004-06-18 09:14:59.000000000 +0200 +++ linux-2.6.7-max/drivers/net/hamradio/dmascc.c 2004-06-18 09:14:59.000000000 +0200 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #include _ From kernel@nn7.de Mon Jun 21 13:24:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 13:24:45 -0700 (PDT) Received: from prosun.first.fraunhofer.de (prosun.first.gmd.de [194.95.168.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LKOfgi003242 for ; Mon, 21 Jun 2004 13:24:42 -0700 Received: from fortknox (localhost [127.0.0.1]) by prosun.first.fraunhofer.de (8.12.10/8.12.10) with ESMTP id i5LKOdqN002361 for ; Mon, 21 Jun 2004 22:24:39 +0200 (MEST) Received: (qmail 11538 invoked from network); 21 Jun 2004 20:28:39 -0000 Received: from unknown (HELO no.intranet.wo.rk) (sonne@192.168.0.123) by fortknox.dyndns.org with RC4-MD5 encrypted SMTPS; 21 Jun 2004 20:28:39 -0000 Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops From: Soeren Sonnenburg To: Herbert Xu Cc: Linux Kernel , davem@redhat.com, Benjamin Herrenschmidt , netdev@oss.sgi.com, jgarzik@pobox.com In-Reply-To: <20040621130316.GA2661@gondor.apana.org.au> References: <1087568322.4455.22.camel@localhost> <20040621130316.GA2661@gondor.apana.org.au> Content-Type: text/plain Message-Id: <1087849459.4146.3.camel@localhost> Mime-Version: 1.0 Date: Mon, 21 Jun 2004 22:24:20 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 6220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@nn7.de Precedence: bulk X-list: netdev On Mon, 2004-06-21 at 15:03, Herbert Xu wrote: > On Mon, Jun 21, 2004 at 10:33:50PM +1000, Herbert Xu wrote: > > > > Does this patch fix your problems? > > Oops, I had a thinko about min vs. max. I've also decided to make the > bigger MTU useful by adjusting the arguments to skb_put() as well. > Please try this one instead. > > Cheers, yes that one works nicely... I tested several mtu's ranging from 1000 to 1500 while the interface was up... no oops. thanks, Soeren. From max@stro.at Mon Jun 21 13:30:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 13:30:34 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LKULgi003635 for ; Mon, 21 Jun 2004 13:30:22 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id C34D55C134 for ; Mon, 21 Jun 2004 21:50: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 07808-04 for ; Mon, 21 Jun 2004 21:50:56 +0200 (CEST) Received: from sputnik (unknown [62.47.155.15]) by baikonur.stro.at (Postfix) with ESMTP id 259EE5C002 for ; Mon, 21 Jun 2004 21:50:56 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1BcUol-0005lI-I1 for netdev@oss.sgi.com; Mon, 21 Jun 2004 21:50:59 +0200 Date: Mon, 21 Jun 2004 21:50:59 +0200 From: maximilian attems To: netdev@oss.sgi.com Subject: [patch-kj] mark __init/__exit static drivers/net/bsd_comp.c Message-ID: <20040621195059.GH1545@sputnik.stro.at> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 6221 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 more static, aplies on 2.6.7, compile tested Signed-off-by: Maximilian Attems --- linux-2.6.7-max/drivers/net/bsd_comp.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/bsd_comp.c~static-bsd_comp drivers/net/bsd_comp.c --- linux-2.6.7/drivers/net/bsd_comp.c~static-bsd_comp 2004-06-18 09:21:30.000000000 +0200 +++ linux-2.6.7-max/drivers/net/bsd_comp.c 2004-06-18 09:21:30.000000000 +0200 @@ -1160,7 +1160,7 @@ static struct compressor ppp_bsd_compres * Module support routines *************************************************************/ -int __init bsdcomp_init(void) +static int __init bsdcomp_init(void) { int answer = ppp_register_compressor(&ppp_bsd_compress); if (answer == 0) @@ -1168,7 +1168,7 @@ int __init bsdcomp_init(void) return answer; } -void __exit bsdcomp_cleanup(void) +static void __exit bsdcomp_cleanup(void) { ppp_unregister_compressor(&ppp_bsd_compress); } From jgarzik@pobox.com Mon Jun 21 13:33:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 13:33: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.12.10/8.12.9) with SMTP id i5LKXGgi003949 for ; Mon, 21 Jun 2004 13:33:17 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbnPS-0002rM-2d; Sat, 19 Jun 2004 22:29:58 +0100 Message-ID: <40D4B049.6070508@pobox.com> Date: Sat, 19 Jun 2004 17:29:45 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [9/9][PATCH 2.6] Add WOL support References: <20040615175003.GA11382@k3.hellgate.ch> In-Reply-To: <20040615175003.GA11382@k3.hellgate.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6222 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 Roger Luethi wrote: > Add rhine_shutdown callback to prepare Rhine power registers for > shutdown. > > Add rhine_get_wol/rhine_set_wol for ethtool ioctl. > > Signed-off-by: Roger Luethi > > --- 2.6-mm/drivers/net/via-rhine.c.orig 2004-06-15 18:34:21.000000000 +0200 > +++ 2.6-mm/drivers/net/via-rhine.c 2004-06-15 18:36:12.000000000 +0200 > @@ -394,8 +394,8 @@ > ConfigA=0x78, ConfigB=0x79, ConfigC=0x7A, ConfigD=0x7B, > RxMissed=0x7C, RxCRCErrs=0x7E, MiscCmd=0x81, > StickyHW=0x83, IntrStatus2=0x84, > - WOLcrSet=0xA0, WOLcrClr=0xA4, WOLcrClr1=0xA6, > - WOLcgClr=0xA7, > + WOLcrSet=0xA0, PwcfgSet=0xA1, WOLcgSet=0xA3, WOLcrClr=0xA4, > + WOLcrClr1=0xA6, WOLcgClr=0xA7, > PwrcsrSet=0xA8, PwrcsrSet1=0xA9, PwrcsrClr=0xAC, PwrcsrClr1=0xAD, > }; > > @@ -427,6 +427,15 @@ > IntrTxErrSummary=0x082218, > }; > > +/* Bits in WOLcrSet/WOLcrClr and PwrcsrSet/PwrcsrClr */ > +enum wol_bits { > + WOLucast = 0x10, > + WOLmagic = 0x20, > + WOLbmcast = 0x30, > + WOLlnkon = 0x40, > + WOLlnkoff = 0x80, > +}; > + > /* The Rx and Tx buffer descriptors. */ > struct rx_desc { > s32 rx_status; > @@ -491,8 +500,8 @@ > unsigned int cur_rx, dirty_rx; /* Producer/consumer ring indices */ > unsigned int cur_tx, dirty_tx; > unsigned int rx_buf_sz; /* Based on MTU+slack. */ > + u8 wolopts; > > - /* These values are keep track of the transceiver/media in use. */ > u8 tx_thresh, rx_thresh; > > struct mii_if_info mii_if; > @@ -512,6 +521,7 @@ > static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); > static struct ethtool_ops netdev_ethtool_ops; > static int rhine_close(struct net_device *dev); > +static void rhine_shutdown (struct device *gdev); > > #define RHINE_WAIT_FOR(condition) do { \ > int i=1024; \ > @@ -537,12 +547,13 @@ > > /* > * Get power related registers into sane state. > - * Returns content of power-event (WOL) registers. > + * Notify user about past WOL event. > */ > static void rhine_power_init(struct net_device *dev) > { > long ioaddr = dev->base_addr; > struct rhine_private *rp = netdev_priv(dev); > + u16 wolstat; > > if (rp->quirks & rqWOL) { > /* Make sure chip is in power state D0 */ > @@ -557,10 +568,40 @@ > if (rp->quirks & rq6patterns) > writeb(0x03, ioaddr + WOLcrClr1); > > + /* Save power-event status bits */ > + wolstat = readb(ioaddr + PwrcsrSet); > + if (rp->quirks & rq6patterns) > + wolstat |= (readb(ioaddr + PwrcsrSet1) & 0x03) << 8; > + > /* Clear power-event status bits */ > writeb(0xFF, ioaddr + PwrcsrClr); > if (rp->quirks & rq6patterns) > writeb(0x03, ioaddr + PwrcsrClr1); > + > + if (wolstat) { > + char *reason; > + switch (wolstat) { > + case WOLmagic: > + reason = "Magic packet"; > + break; > + case WOLlnkon: > + reason = "Link went up"; > + break; > + case WOLlnkoff: > + reason = "Link went down"; > + break; > + case WOLucast: > + reason = "Unicast packet"; > + break; > + case WOLbmcast: > + reason = "Multicast/broadcast packet"; > + break; > + default: > + reason = "Unknown"; > + } > + printk("%s: Woke system up. Reason: %s.\n", > + DRV_NAME, reason); printk needs KERN_xxx prefix also, use dev->name rather than DRV_NAME, since we are past the probe phase. > + } > } > } > > @@ -1766,6 +1807,39 @@ > debug = value; > } > > +static void rhine_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) > +{ > + struct rhine_private *rp = netdev_priv(dev); > + > + if (!(rp->quirks & rqWOL)) > + return; is WOL really considered a quirk? ;-) > + spin_lock_irq(&rp->lock); > + wol->supported = WAKE_PHY | WAKE_MAGIC | > + WAKE_UCAST | WAKE_MCAST | WAKE_BCAST; /* Untested */ > + wol->wolopts = rp->wolopts; > + spin_unlock_irq(&rp->lock); > +} > + > +static int rhine_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) > +{ > + struct rhine_private *rp = netdev_priv(dev); > + u32 support = WAKE_PHY | WAKE_MAGIC | > + WAKE_UCAST | WAKE_MCAST | WAKE_BCAST; /* Untested */ > + > + if (!(rp->quirks & rqWOL)) > + return -EINVAL; > + > + if (wol->wolopts & ~support) > + return -EINVAL; > + > + spin_lock_irq(&rp->lock); > + rp->wolopts = wol->wolopts; > + spin_unlock_irq(&rp->lock); > + > + return 0; > +} > + > static struct ethtool_ops netdev_ethtool_ops = { > .get_drvinfo = netdev_get_drvinfo, > .get_settings = netdev_get_settings, > @@ -1774,6 +1848,8 @@ > .get_link = netdev_get_link, > .get_msglevel = netdev_get_msglevel, > .set_msglevel = netdev_set_msglevel, > + .get_wol = rhine_get_wol, > + .set_wol = rhine_set_wol, > .get_sg = ethtool_op_get_sg, > .get_tx_csum = ethtool_op_get_tx_csum, > }; > @@ -1844,12 +1920,51 @@ > pci_set_drvdata(pdev, NULL); > } > > +static void rhine_shutdown (struct device *gendev) > +{ > + struct pci_dev *pdev = to_pci_dev(gendev); > + struct net_device *dev = pci_get_drvdata(pdev); > + struct rhine_private *rp = netdev_priv(dev); > + > + long ioaddr = dev->base_addr; > + > + rhine_power_init(dev); > + > + /* Make sure we use pattern 0, 1 and not 4, 5 */ > + if (rp->quirks & rq6patterns) > + writeb(0x04, ioaddr + 0xA7); > + > + if (rp->wolopts & WAKE_MAGIC) > + writeb(WOLmagic, ioaddr + WOLcrSet); > + > + if (rp->wolopts & (WAKE_BCAST|WAKE_MCAST)) > + writeb(WOLbmcast, ioaddr + WOLcgSet); > + > + if (rp->wolopts & WAKE_PHY) > + writeb(WOLlnkon | WOLlnkoff, ioaddr + WOLcrSet); > + > + if (rp->wolopts & WAKE_UCAST) > + writeb(WOLucast, ioaddr + WOLcrSet); > + > + /* Enable legacy WOL (for old motherboards) */ > + writeb(0x01, ioaddr + PwcfgSet); > + writeb(readb(ioaddr + StickyHW) | 0x04, ioaddr + StickyHW); > + > + /* Hit power state D3 (sleep) */ > + writeb(readb(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW); would be nice to eliminate these magic numbers (0x04, 0x04), ... > + /* TODO: Check use of pci_enable_wake() */ > + > +} > > static struct pci_driver rhine_driver = { > .name = DRV_NAME, > .id_table = rhine_pci_tbl, > .probe = rhine_init_one, > .remove = __devexit_p(rhine_remove_one), > + .driver = { > + .shutdown = rhine_shutdown, > + } > }; > > From manuel@todo-linux.com Mon Jun 21 13:38:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 13:38:15 -0700 (PDT) Received: from mx.larebelion.net (zulo.virutass.net [62.151.20.186]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LKc8gi004369 for ; Mon, 21 Jun 2004 13:38:09 -0700 Received: from amavis by mx.larebelion.net with scanned-ok id 1BcPHj-0000GS-00 for netdev@oss.sgi.com; Mon, 21 Jun 2004 15:56:31 +0200 Received: from [213.172.57.129] (helo=Linux) by mx.larebelion.net with asmtp id 1BcPHh-0000Fc-00; Mon, 21 Jun 2004 15:56:29 +0200 From: Manuel Arostegui Ramirez To: Herbert Xu , kernel@nn7.de (Soeren Sonnenburg) Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops Date: Mon, 21 Jun 2004 15:56:20 +0200 User-Agent: KMail/1.5 Cc: linux-kernel@vger.kernel.org, davem@redhat.com, benh@kernel.crashing.org, netdev@oss.sgi.com, jgarzik@pobox.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200406211556.20020.manuel@todo-linux.com> X-Virus: by Larebelion Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5LKc8gi004369 X-archive-position: 6223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manuel@todo-linux.com Precedence: bulk X-list: netdev El Lunes 21 Junio 2004 14:33, Herbert Xu escribi: > Soeren Sonnenburg wrote: > > When I have some ethernet connection and then do: > > > > ifconfig eth0 mtu 1300 > > > > I get an immediate kernel panic (kernel 2.6.6) on a powerbook g4 15" > > 1ghz. > > > > xmon trace (jpeg) is here: http://www.nn7.de/kernel/mtu1300.jpg (use a > > webbrowser to view it as it is a redirect) > > > > this is 100% reproducable here so I hope it is more easy to fix. > > Does this patch fix your problems? > > Cheers, > > > >===== drivers/net/sungem.c 1.56 vs edited ===== > >--- 1.56/drivers/net/sungem.c 2004-06-19 17:16:13 +10:00 > >+++ edited/drivers/net/sungem.c 2004-06-21 22:28:40 +10:00 > >@@ -33,6 +33,7 @@ > > #include > > #include > > #include > >+#include > > > > #include > > #include > >@@ -742,7 +743,7 @@ > > PCI_DMA_FROMDEVICE); > > gp->rx_skbs[entry] = new_skb; > > new_skb->dev = gp->dev; > >- skb_put(new_skb, (ETH_FRAME_LEN + RX_OFFSET)); > >+ skb_put(new_skb, (VLAN_ETH_FRAME_LEN + RX_OFFSET)); > > rxd->buffer = cpu_to_le64(pci_map_page(gp->pdev, > > > >virt_to_page(new_skb->data), > > > >offset_in_page(new_skb->data), > >@@ -1482,6 +1483,9 @@ > > > > gem_clean_rings(gp); > > > >+ gp->rx_buf_sz = min(dev->mtu + ETH_HLEN + VLAN_HLEN, > >+ (unsigned)VLAN_ETH_FRAME_LEN); > >+ > > for (i = 0; i < RX_RING_SIZE; i++) { > > struct sk_buff *skb; > > struct gem_rxd *rxd = &gb->rxd[i]; > >@@ -1495,7 +1499,7 @@ > > > > gp->rx_skbs[i] = skb; > > skb->dev = dev; > >- skb_put(skb, (ETH_FRAME_LEN + RX_OFFSET)); > >+ skb_put(skb, (VLAN_ETH_FRAME_LEN + RX_OFFSET)); > > dma_addr = pci_map_page(gp->pdev, > > virt_to_page(skb->data), > > offset_in_page(skb->data), > >===== drivers/net/sungem.h 1.14 vs edited ===== > >--- 1.14/drivers/net/sungem.h 2004-01-26 18:03:59 +11:00 > >+++ edited/drivers/net/sungem.h 2004-06-21 22:24:46 +10:00 > >@@ -911,7 +911,7 @@ > > (GP)->tx_old - (GP)->tx_new - 1) > > #define RX_OFFSET 2 > >-#define RX_BUF_ALLOC_SIZE(gp) ((gp)->dev->mtu + 46 + RX_OFFSET + 64) > >+#define RX_BUF_ALLOC_SIZE(gp) ((gp)->rx_buf_sz + 32 + RX_OFFSET + 64) > > > > #define RX_COPY_THRESHOLD 256 > > > >@@ -979,6 +979,7 @@ > > int rx_fifo_sz; > > int rx_pause_off; > > int rx_pause_on; > >+ int rx_buf_sz; > > int mii_phy_addr; > > > > u32 mac_rx_cfg; I've had the same problem, like Soeren, but if i put MTU=1200 there is not kernel panic. I'm going to patch my 2.6.6 with this patch, thanks Herbert. Best regards From davem@redhat.com Mon Jun 21 14:12:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 14:12:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LLCLgi005464 for ; Mon, 21 Jun 2004 14:12: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 i5LLC7e1006627; Mon, 21 Jun 2004 17:12:07 -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 i5LLC7011266; Mon, 21 Jun 2004 17:12:07 -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 i5LLBkot017239; Mon, 21 Jun 2004 17:11:46 -0400 Date: Mon, 21 Jun 2004 14:11:44 -0700 From: "David S. Miller" To: Herbert Xu Cc: kernel@nn7.de, linux-kernel@vger.kernel.org, benh@kernel.crashing.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops Message-Id: <20040621141144.119be627.davem@redhat.com> In-Reply-To: <20040621130316.GA2661@gondor.apana.org.au> References: <1087568322.4455.22.camel@localhost> <20040621130316.GA2661@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: 6224 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 Mon, 21 Jun 2004 23:03:16 +1000 Herbert Xu wrote: > On Mon, Jun 21, 2004 at 10:33:50PM +1000, Herbert Xu wrote: > > > > Does this patch fix your problems? > > Oops, I had a thinko about min vs. max. I've also decided to make the > bigger MTU useful by adjusting the arguments to skb_put() as well. > Please try this one instead. Applied, thanks Herbert. From dlstevens@us.ibm.com Mon Jun 21 14:18:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 14:19:00 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LLIvgi005912 for ; Mon, 21 Jun 2004 14:18:58 -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.2) with ESMTP id i5LLIKur590974; Mon, 21 Jun 2004 17:18:22 -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 i5LLIASV342142; Mon, 21 Jun 2004 15:18:11 -0600 In-Reply-To: <20040621181146.20bde98%hibi665@oki.com> To: Takashi Hibi Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: About MLDv2 specification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Mon, 21 Jun 2004 14:06:00 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/21/2004 15:18:11, Serialize complete at 06/21/2004 15:18:11 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 6225 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 Takashi, I believe your patch will work in suppressing empty MODE_IS_INCLUDE, but in the event the report for an empty MODE_IS_INCLUDE is the only record, it'll still go through the timer for all the retransmits. I want to see how hard it'd be not to start the report timer at all for this case, and also make sure any other changes are taken care of. The patch looks ok to me for the interim, though. +-DLS From kangur@polcom.net Mon Jun 21 14:49:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 14:50:00 -0700 (PDT) Received: from alpha.polcom.net ([80.72.36.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LLnqgi007741 for ; Mon, 21 Jun 2004 14:49:56 -0700 Received: from localhost (localhost.lo [127.0.0.1]) by alpha.polcom.net (Postfix) with ESMTP id 97FDD2BE7; Mon, 21 Jun 2004 23:49:51 +0200 (CEST) Received: from alpha.polcom.net ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13654-05; Mon, 21 Jun 2004 23:49:48 +0200 (CEST) Received: from localhost (localhost.lo [127.0.0.1]) by alpha.polcom.net (Postfix) with ESMTP id 44306E83; Mon, 21 Jun 2004 23:49:48 +0200 (CEST) Date: Mon, 21 Jun 2004 23:49:48 +0200 (CEST) From: Grzegorz Kulewski Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, akpm@osdl.org, kangur@polcom.net Subject: network related(?) kernel panic (2.6.7-bk4) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at alpha.polcom.net X-archive-position: 6226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kangur@polcom.net Precedence: bulk X-list: netdev I have sent this to LKML but I forward it to you. Hi, I am testing 2.6.7-bk4 + timer fix + vesafb-tng patch. This time without debuging compiled in. Everything worked perfectly before I got: bad: scheduling while atomic! schedule+0x466/0x470 do_page_fault+0x104/0x4c1 ip_route_output_flow+0x22/0x70 sys_sched_yield+0x3f/0x50 coredump_wait+0x31/0xa0 do_coredump+0xf1/0x1af sockfd_lookup+0x16/0x80 do_page_fault+0x0/0x4c1 error_code+0x2d/0x38 __dequeue_signal+0xc6/0x160 dequeue_signal+0x23/0x80 get_signal_to_deriver+0x246/0x330 do_signal+0x85/0x100 __sock_create+0x191/0x260 sys_send+0x37/0x40 sys_socketcall+0x12f/0x250 copy_to_user+0x32/0x50 do_page_fault+0x0/0x4c1 do_notify_resume+0x35/0x38 work_notifysig+0x13/0x15 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing (sorry for any mistakes - I copied it by hand). The kernel was not tainted. I can reproduce the same every time I want to connect to the network. I use speedtouch kernel driver. I have script that first executes modem_run then pppd then wget to change DNS entries to new IP adress. This happens after pppd setups connection and gets IP. I think that this happens in wget. This works with 2.6.7, so some recent bk change is probably the cause. Can you help me? Thanks, Grzegorz Kulewski From romieu@fr.zoreil.com Mon Jun 21 14:58:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 14:58:48 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LLwggi008161 for ; Mon, 21 Jun 2004 14:58:43 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5LLw9on009984; Mon, 21 Jun 2004 23:58:09 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5LLw8DT009983; Mon, 21 Jun 2004 23:58:08 +0200 Date: Mon, 21 Jun 2004 23:58:08 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-mm1 2/4] via-velocity: Rx copybreak Message-ID: <20040621235808.A9979@electric-eye.fr.zoreil.com> References: <20040621235615.A7869@electric-eye.fr.zoreil.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: <20040621235615.A7869@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Jun 21, 2004 at 11:56:15PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6228 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 Handle copybreak. - velocity_rx_refill() is modified to allow the processing of a Rx desc ring wherein the empty skb slots are not necessarily contiguous. Given the preceeding changes, rx_copybreak should not need anything else; - the driver does not rely on rd_info->skb_dma set to NULL any more; - pci_dma_sync_single_for_{cpu/device} changes as a bonus; - more function documentation. Some inspiration borrowed from similar r8169 code. diff -puN drivers/net/via-velocity.c~via-velocity-60 drivers/net/via-velocity.c --- linux-2.6.7/drivers/net/via-velocity.c~via-velocity-60 2004-06-21 21:50:55.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/via-velocity.c 2004-06-21 21:50:55.000000000 +0200 @@ -226,6 +226,10 @@ VELOCITY_PARAM(wol_opts, "Wake On Lan op VELOCITY_PARAM(int_works, "Number of packets per interrupt services"); +static int rx_copybreak = 200; +MODULE_PARM(rx_copybreak, "i"); +MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for copy-only-tiny-frames"); + static int velocity_found1(struct pci_dev *pdev, const struct pci_device_id *ent); static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr, struct velocity_info_tbl *info); static int velocity_get_pci_info(struct velocity_info *, struct pci_dev *pdev); @@ -1004,13 +1008,22 @@ static int velocity_rx_refill(struct vel { int dirty = vptr->rd_dirty, done = 0, ret = 0; - while (!vptr->rd_info[dirty].skb) { - ret = velocity_alloc_rx_buf(vptr, dirty); - if (ret < 0) + do { + 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)) break; + + if (!vptr->rd_info[dirty].skb) { + ret = velocity_alloc_rx_buf(vptr, dirty); + if (ret < 0) + break; + } done++; dirty = (dirty < vptr->options.numrx - 1) ? dirty + 1 : 0; - } + } while (dirty != vptr->rd_curr); + if (done) { vptr->rd_dirty = dirty; vptr->rd_filled += done; @@ -1069,7 +1082,7 @@ static void velocity_free_rd_ring(struct for (i = 0; i < vptr->options.numrx; i++) { struct velocity_rd_info *rd_info = &(vptr->rd_info[i]); - if (!rd_info->skb_dma) + if (!rd_info->skb) continue; pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx_buf_sz, PCI_DMA_FROMDEVICE); @@ -1205,7 +1218,6 @@ static int velocity_rx_srv(struct veloci /* * Don't drop CE or RL error frame although RXOK is off - * FIXME: need to handle copybreak */ if ((rd->rdesc0.RSR & RSR_RXOK) || (!(rd->rdesc0.RSR & RSR_RXOK) && (rd->rdesc0.RSR & (RSR_CE | RSR_RL)))) { if (velocity_receive_frame(vptr, rd_curr) < 0) @@ -1265,6 +1277,43 @@ static inline void velocity_rx_csum(stru } /** + * velocity_rx_copy - in place Rx copy for small packets + * @rx_skb: network layer packet buffer candidate + * @pkt_size: received data size + * @rd: receive packet descriptor + * @dev: network device + * + * Replace the current skb that is scheduled for Rx processing by a + * shorter, immediatly allocated skb, if the received packet is small + * enough. This function returns a negative value if the received + * packet is too big or if memory is exhausted. + */ +static inline int velocity_rx_copy(struct sk_buff **rx_skb, int pkt_size, + struct velocity_info *vptr) +{ + int ret = -1; + + if (pkt_size < rx_copybreak) { + struct sk_buff *new_skb; + + new_skb = dev_alloc_skb(pkt_size + 2); + if (new_skb) { + new_skb->dev = vptr->dev; + new_skb->ip_summed = rx_skb[0]->ip_summed; + + if (vptr->flags & VELOCITY_FLAGS_IP_ALIGN) + skb_reserve(new_skb, 2); + + memcpy(new_skb->data, rx_skb[0]->tail, pkt_size); + *rx_skb = new_skb; + ret = 0; + } + + } + return ret; +} + +/** * velocity_iph_realign - IP header alignment * @vptr: velocity we are handling * @skb: network layer packet buffer @@ -1297,6 +1346,7 @@ static inline void velocity_iph_realign( static int velocity_receive_frame(struct velocity_info *vptr, int idx) { + void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int); struct net_device_stats *stats = &vptr->stats; struct velocity_rd_info *rd_info = &(vptr->rd_info[idx]); struct rx_desc *rd = &(vptr->rd_ring[idx]); @@ -1315,15 +1365,8 @@ static int velocity_receive_frame(struct skb = rd_info->skb; skb->dev = vptr->dev; - pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx_buf_sz, - PCI_DMA_FROMDEVICE); - rd_info->skb_dma = (dma_addr_t) NULL; - rd_info->skb = NULL; - - velocity_iph_realign(vptr, skb, pkt_len); - - skb_put(skb, pkt_len - 4); - skb->protocol = eth_type_trans(skb, skb->dev); + pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma, + vptr->rx_buf_sz, PCI_DMA_FROMDEVICE); /* * Drop frame not meeting IEEE 802.3 @@ -1336,11 +1379,21 @@ static int velocity_receive_frame(struct } } + pci_action = pci_dma_sync_single_for_device; + velocity_rx_csum(rd, skb); - - /* - * FIXME: need rx_copybreak handling - */ + + if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) { + velocity_iph_realign(vptr, skb, pkt_len); + pci_action = pci_unmap_single; + rd_info->skb = NULL; + } + + pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx_buf_sz, + PCI_DMA_FROMDEVICE); + + skb_put(skb, pkt_len - 4); + skb->protocol = eth_type_trans(skb, skb->dev); stats->rx_bytes += pkt_len; netif_rx(skb); _ From romieu@fr.zoreil.com Mon Jun 21 14:58:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 14:58:46 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LLwggi008160 for ; Mon, 21 Jun 2004 14:58:43 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5LLuGon009978; Mon, 21 Jun 2004 23:56:16 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5LLuFVD009977; Mon, 21 Jun 2004 23:56:15 +0200 Date: Mon, 21 Jun 2004 23:56:15 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-mm1 1/4] via-velocity: Rx buffers allocation rework Message-ID: <20040621235615.A7869@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 6227 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 Rework of the Rx buffers allocation: - Rx irq handler (velocity_rx_srv): defer the Rx buffer allocation until the packet processing loop is done; - a separate index related to the Rx descriptor ("rd_dirty") is introduced to distinguish the first Rx descriptor whose buffer has to be refilled. This way the driver does not need to confuse this descriptor with the most recently netif()ed one. Rationale: batch + rx_copybreak; - dirty/empty Rx descriptors are identified through the whole driver via an adequate NULL pointer in the velocity_rd_info[] array (see velocity_rx_refill() and velocity_receive_frame()); - Rx descriptors need to be grouped by a multiple of 4 before they can be handed back to the asic (hardware constraint). This task is moved from the Rx processing loop to the Rx refill function; - factorization of code in velocity_init_rd_ring(). diff -puN drivers/net/via-velocity.c~via-velocity-50 drivers/net/via-velocity.c --- linux-2.6.7/drivers/net/via-velocity.c~via-velocity-50 2004-06-21 21:38:34.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/via-velocity.c 2004-06-21 21:40:41.000000000 +0200 @@ -482,7 +482,7 @@ static void velocity_rx_reset(struct vel struct mac_regs * regs = vptr->mac_regs; int i; - vptr->rd_used = vptr->rd_curr = 0; + vptr->rd_dirty = vptr->rd_filled = vptr->rd_curr = 0; /* * Init state, all RD entries belong to the NIC @@ -977,6 +977,49 @@ static void velocity_free_rings(struct v pci_free_consistent(vptr->pdev, size, vptr->tx_bufs, vptr->tx_bufs_dma); } +static inline void velocity_give_many_rx_descs(struct velocity_info *vptr) +{ + struct mac_regs *regs = vptr->mac_regs; + int avail, dirty, unusable; + + /* + * RD number must be equal to 4X per hardware spec + * (programming guide rev 1.20, p.13) + */ + if (vptr->rd_filled < 4) + return; + + unusable = vptr->rd_filled | 0x0003; + 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); + } + + writew(vptr->rd_filled & 0xfffc, ®s->RBRDU); + vptr->rd_filled = unusable; +} + +static int velocity_rx_refill(struct velocity_info *vptr) +{ + int dirty = vptr->rd_dirty, done = 0, ret = 0; + + while (!vptr->rd_info[dirty].skb) { + ret = velocity_alloc_rx_buf(vptr, dirty); + if (ret < 0) + break; + done++; + dirty = (dirty < vptr->options.numrx - 1) ? dirty + 1 : 0; + } + if (done) { + vptr->rd_dirty = dirty; + vptr->rd_filled += done; + velocity_give_many_rx_descs(vptr); + } + + return ret; +} + /** * velocity_init_rd_ring - set up receive ring * @vptr: velocity to configure @@ -987,9 +1030,7 @@ static void velocity_free_rings(struct v static int velocity_init_rd_ring(struct velocity_info *vptr) { - int i, ret = -ENOMEM; - struct rx_desc *rd; - struct velocity_rd_info *rd_info; + int ret = -ENOMEM; unsigned int rsize = sizeof(struct velocity_rd_info) * vptr->options.numrx; @@ -998,22 +1039,14 @@ static int velocity_init_rd_ring(struct goto out; memset(vptr->rd_info, 0, rsize); - /* Init the RD ring entries */ - for (i = 0; i < vptr->options.numrx; i++) { - rd = &(vptr->rd_ring[i]); - rd_info = &(vptr->rd_info[i]); + vptr->rd_filled = vptr->rd_dirty = vptr->rd_curr = 0; - ret = velocity_alloc_rx_buf(vptr, i); - if (ret < 0) { - VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR - "%s: failed to allocate RX buffer.\n", - vptr->dev->name); - velocity_free_rd_ring(vptr); - goto out; - } - velocity_give_rx_desc(rd); + ret = velocity_rx_refill(vptr); + if (ret < 0) { + VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR + "%s: failed to allocate RX buffer.\n", vptr->dev->name); + velocity_free_rd_ring(vptr); } - vptr->rd_used = vptr->rd_curr = 0; out: return ret; } @@ -1157,22 +1190,14 @@ static void velocity_free_td_ring(struct static int velocity_rx_srv(struct velocity_info *vptr, int status) { - struct rx_desc *rd; struct net_device_stats *stats = &vptr->stats; - struct mac_regs * regs = vptr->mac_regs; int rd_curr = vptr->rd_curr; int works = 0; while (1) { + struct rx_desc *rd = vptr->rd_ring + rd_curr; - rd = &(vptr->rd_ring[rd_curr]); - - if ((vptr->rd_info[rd_curr]).skb == NULL) { - if (velocity_alloc_rx_buf(vptr, rd_curr) < 0) - break; - } - - if (works++ > 15) + if (!vptr->rd_info[rd_curr].skb || (works++ > 15)) break; if (rd->rdesc0.owner == OWNED_BY_NIC) @@ -1183,14 +1208,8 @@ static int velocity_rx_srv(struct veloci * FIXME: need to handle copybreak */ if ((rd->rdesc0.RSR & RSR_RXOK) || (!(rd->rdesc0.RSR & RSR_RXOK) && (rd->rdesc0.RSR & (RSR_CE | RSR_RL)))) { - if (velocity_receive_frame(vptr, rd_curr) == 0) { - if (velocity_alloc_rx_buf(vptr, rd_curr) < 0) { - VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR "%s: can not allocate rx buf\n", vptr->dev->name); - break; - } - } else { + if (velocity_receive_frame(vptr, rd_curr) < 0) stats->rx_dropped++; - } } else { if (rd->rdesc0.RSR & RSR_CRC) stats->rx_crc_errors++; @@ -1202,24 +1221,18 @@ static int velocity_rx_srv(struct veloci rd->inten = 1; - if (++vptr->rd_used >= 4) { - int i, rd_prev = rd_curr; - for (i = 0; i < 4; i++) { - if (--rd_prev < 0) - rd_prev = vptr->options.numrx - 1; - - velocity_give_rx_desc(vptr->rd_ring + rd_prev); - } - writew(4, &(regs->RBRDU)); - vptr->rd_used -= 4; - } - vptr->dev->last_rx = jiffies; rd_curr++; if (rd_curr >= vptr->options.numrx) rd_curr = 0; } + + if (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; diff -puN drivers/net/via-velocity.h~via-velocity-50 drivers/net/via-velocity.h --- linux-2.6.7/drivers/net/via-velocity.h~via-velocity-50 2004-06-21 21:38:34.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/via-velocity.h 2004-06-21 21:38:34.000000000 +0200 @@ -1771,7 +1771,8 @@ struct velocity_info { struct velocity_td_info *td_infos[TX_QUEUE_NO]; int rd_curr; - int rd_used; + int rd_dirty; + u32 rd_filled; struct rx_desc *rd_ring; struct velocity_rd_info *rd_info; /* It's an array */ _ From romieu@fr.zoreil.com Mon Jun 21 15:02:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 15:02:44 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LM2egi008848 for ; Mon, 21 Jun 2004 15:02:41 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5LM1Bon010068; Tue, 22 Jun 2004 00:01:11 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5LM1BLe010067; Tue, 22 Jun 2004 00:01:11 +0200 Date: Tue, 22 Jun 2004 00:01:11 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-mm1 4/4] via-velocity: unneeded forward declarations Message-ID: <20040622000111.C9979@electric-eye.fr.zoreil.com> References: <20040621235615.A7869@electric-eye.fr.zoreil.com> <20040621235808.A9979@electric-eye.fr.zoreil.com> <20040621235946.B9979@electric-eye.fr.zoreil.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: <20040621235946.B9979@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Jun 21, 2004 at 11:59:46PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6230 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 Removal of unneeded forward declarations. diff -puN drivers/net/via-velocity.c~via-velocity-100 drivers/net/via-velocity.c --- linux-2.6.7/drivers/net/via-velocity.c~via-velocity-100 2004-06-21 22:20:53.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/via-velocity.c 2004-06-21 23:46:19.000000000 +0200 @@ -230,7 +230,6 @@ static int rx_copybreak = 200; MODULE_PARM(rx_copybreak, "i"); MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for copy-only-tiny-frames"); -static int velocity_found1(struct pci_dev *pdev, const struct pci_device_id *ent); static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr, struct velocity_info_tbl *info); static int velocity_get_pci_info(struct velocity_info *, struct pci_dev *pdev); static void velocity_print_info(struct velocity_info *vptr); @@ -242,10 +241,8 @@ static void velocity_set_multi(struct ne static struct net_device_stats *velocity_get_stats(struct net_device *dev); static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); static int velocity_close(struct net_device *dev); -static int velocity_rx_srv(struct velocity_info *vptr, int status); static int velocity_receive_frame(struct velocity_info *, int idx); static int velocity_alloc_rx_buf(struct velocity_info *, int idx); -static void velocity_init_registers(struct velocity_info *vptr, enum velocity_init_type type); static void velocity_free_rd_ring(struct velocity_info *vptr); static void velocity_free_tx_buf(struct velocity_info *vptr, struct velocity_td_info *); static int velocity_soft_reset(struct velocity_info *vptr); @@ -260,7 +257,6 @@ static int velocity_mii_read(struct mac_ static int velocity_mii_write(struct mac_regs *, u8 byMiiAddr, u16 data); static u32 mii_check_media_mode(struct mac_regs * regs); static u32 check_connection_type(struct mac_regs * regs); -static void velocity_init_cam_filter(struct velocity_info *vptr); static int velocity_set_media_mode(struct velocity_info *vptr, u32 mii_status); #ifdef CONFIG_PM _ From romieu@fr.zoreil.com Mon Jun 21 15:02:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 15:02:43 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LM2egi008847 for ; Mon, 21 Jun 2004 15:02:41 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5LLxlon010038; Mon, 21 Jun 2004 23:59:47 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5LLxkkO010037; Mon, 21 Jun 2004 23:59:46 +0200 Date: Mon, 21 Jun 2004 23:59:46 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-mm1 3/4] via-velocity: ordering of Rx descriptors operations Message-ID: <20040621235946.B9979@electric-eye.fr.zoreil.com> References: <20040621235615.A7869@electric-eye.fr.zoreil.com> <20040621235808.A9979@electric-eye.fr.zoreil.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: <20040621235808.A9979@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Jun 21, 2004 at 11:58:08PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 6229 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 Force strict ordering of operations on Rx descriptors to avoid any issue related to inline optimization. diff -puN drivers/net/via-velocity.c~via-velocity-80 drivers/net/via-velocity.c --- linux-2.6.7/drivers/net/via-velocity.c~via-velocity-80 2004-06-21 21:51:15.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/via-velocity.c 2004-06-21 22:20:35.000000000 +0200 @@ -993,6 +993,8 @@ static inline void velocity_give_many_rx if (vptr->rd_filled < 4) return; + wmb(); + unusable = vptr->rd_filled | 0x0003; dirty = vptr->rd_dirty - unusable + 1; for (avail = vptr->rd_filled & 0xfffc; avail; avail--) { _ From yoshfuji@linux-ipv6.org Mon Jun 21 16:50:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 16:50:28 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LNoMgi016621 for ; Mon, 21 Jun 2004 16:50:24 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D624D33CE5; Tue, 22 Jun 2004 08:51:23 +0900 (JST) Date: Tue, 22 Jun 2004 08:51:21 +0900 (JST) Message-Id: <20040622.085121.05747685.yoshfuji@linux-ipv6.org> To: max@stro.at Cc: romieu@fr.zoreil.com, janitor@sternwelten.at, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040621200420.GI1545@sputnik.stro.at> References: <20040621171832.GE1545@sputnik.stro.at> <20040622.032138.58652005.yoshfuji@linux-ipv6.org> <20040621200420.GI1545@sputnik.stro.at> 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: 6231 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 <20040621200420.GI1545@sputnik.stro.at> (at Mon, 21 Jun 2004 22:04:20 +0200), maximilian attems says: > doesn't seem to be enough, > because if (tb == NULL) fn_hash_kmem won't be freed, > or am i overseeing something? I believe fn_hash_kmem is not required to (and should not) be freed even if kmalloc() fails for the new table. Users in existing table should be able to continue using fn_hash_kmem. --yoshfuji From kumarkr@us.ibm.com Mon Jun 21 16:55:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 16:55:39 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5LNtagi017965 for ; Mon, 21 Jun 2004 16:55:37 -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.2) with ESMTP id i5LNtEur646704; Mon, 21 Jun 2004 19:55:14 -0400 Received: from d03nm132.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 i5LNtDSU387290; Mon, 21 Jun 2004 17:55:13 -0600 Subject: Re: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create() To: maximilian attems Cc: janitor@sternwelten.at, netdev@oss.sgi.com, romieu@fr.zoreil.com, "YOSHIFUJI Hideaki / ?$B5HF#1QL@" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Mon, 21 Jun 2004 16:52:47 -0700 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 06/21/2004 17:55:13 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253" X-archive-position: 6232 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 --0__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253 Content-type: multipart/alternative; Boundary="1__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253" --1__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253 Content-type: text/plain; charset=US-ASCII > doesn't seem to be enough, > because if (tb == NULL) fn_hash_kmem won't be freed, > or am i overseeing something? Your patch doesn't seem to fix the real problem (and fn_hash_kmem is not getting leaked, the 'leak' seems intentional to keep using it even if other allocations in the same routine failed. The question is should we free all allocated memory and fail the load since these pointers are used without checking in some ipv4 code (eg fib_lookup) ? Eg. ip_rt_init() return -ENOMEM on memory failure, but ip_init() doesn't check the value and neither does inet_init() which calls ip_init(). Should the entire startup sequence be cleaned up to check return values ? Why continue ipv6 load if some 160 odd bytes are not available on the system ? (BTW, this code is buggy only if IP_MULTIPLE_TABLES is not defined.) Thanks, - KK |---------+----------------------------> | | maximilian attems| | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 06/21/2004 01:04 | | | PM | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------| | | | To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" | | cc: romieu@fr.zoreil.com, janitor@sternwelten.at, netdev@oss.sgi.com | | Subject: Re: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create() | | | >---------------------------------------------------------------------------------------------------------------| On Tue, 22 Jun 2004, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <20040621171832.GE1545@sputnik.stro.at> (at Mon, 21 Jun 2004 19:18:32 +0200), maximilian attems says: > > > From: Francois Romieu > > > > kmem_cache_create leak. > > > > Note: fib_hash_init() can be called many times. > > > > Signed-off-by: Maximilian Attems > > Please tell us what kind of leakage do you see? > Is it just enough to return NULL if kmem_cache_create() fails > like this? > > --- a/net/ipv4/fib_hash.c 10 Nov 2003 23:40:57 -0000 1.1.1.13 > +++ b/net/ipv4/fib_hash.c 21 Jun 2004 18:19:16 -0000 > @@ -871,12 +871,14 @@ > { > struct fib_table *tb; > > - if (fn_hash_kmem == NULL) > + if (fn_hash_kmem == NULL) { > fn_hash_kmem = kmem_cache_create("ip_fib_hash", > sizeof(struct fib_node), > 0, SLAB_HWCACHE_ALIGN, > NULL, NULL); > - > + if (fn_hash_kmem == NULL) > + return NULL; > + } > tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL); > if (tb == NULL) > return NULL; doesn't seem to be enough, because if (tb == NULL) fn_hash_kmem won't be freed, or am i overseeing something? a++ maks --1__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> doesn't seem to be enough,
> because if (tb == NULL) fn_hash_kmem won't be freed,
> or am i overseeing something?

Your patch doesn't seem to fix the real problem (and fn_hash_kmem
is not getting leaked, the 'leak' seems intentional to keep using
it even if other allocations in the same routine failed.

The question is should we free all allocated memory and fail the
load since these pointers are used without checking in some ipv4
code (eg fib_lookup) ? Eg. ip_rt_init() return -ENOMEM on memory
failure, but ip_init() doesn't check the value and neither does
inet_init() which calls ip_init(). Should the entire startup
sequence be cleaned up to check return values ? Why continue ipv6
load if some 160 odd bytes are not available on the system ?

(BTW, this code is buggy only if IP_MULTIPLE_TABLES is not defined.)

Thanks,

- KK

Inactive hide details for maximilian attems <max@stro.at>maximilian attems <max@stro.at>




          maximilian attems <max@stro.at>
          Sent by: netdev-bounce@oss.sgi.com

          06/21/2004 01:04 PM



To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org>
cc: romieu@fr.zoreil.com, janitor@sternwelten.at, netdev@oss.sgi.com
Subject: Re: [patch-kj] net/ipv4/fib_hash.c: check kmem_cache_create()


On Tue, 22 Jun 2004, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:

> In article <20040621171832.GE1545@sputnik.stro.at> (at Mon, 21 Jun 2004 19:18:32 +0200), maximilian attems <janitor@sternwelten.at> says:
>
> > From: Francois Romieu <romieu@fr.zoreil.com>
> >
> > kmem_cache_create leak.
> >
> > Note: fib_hash_init() can be called many times.
> >
> > Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
>
> Please tell us what kind of leakage do you see?
> Is it just enough to return NULL if kmem_cache_create() fails
> like this?
>
> --- a/net/ipv4/fib_hash.c 10 Nov 2003 23:40:57 -0000 1.1.1.13
> +++ b/net/ipv4/fib_hash.c 21 Jun 2004 18:19:16 -0000
> @@ -871,12 +871,14 @@
> {
> struct fib_table *tb;
>
> - if (fn_hash_kmem == NULL)
> + if (fn_hash_kmem == NULL) {
> fn_hash_kmem = kmem_cache_create("ip_fib_hash",
> sizeof(struct fib_node),
> 0, SLAB_HWCACHE_ALIGN,
> NULL, NULL);
> -
> + if (fn_hash_kmem == NULL)
> + return NULL;
> + }
> tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL);
> if (tb == NULL)
> return NULL;

doesn't seem to be enough,
because if (tb == NULL) fn_hash_kmem won't be freed,
or am i overseeing something?

a++ maks


 --1__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253-- --0__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=07BBE429DFE202538f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=07BBE429DFE202538f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253 Content-type: image/gif; name="pic05285.gif" Content-Disposition: inline; filename="pic05285.gif" Content-ID: <30__=07BBE429DFE202538f9e8a93df938@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__=07BBE429DFE202538f9e8a93df938690918c07BBE429DFE20253-- From jgarzik@pobox.com Mon Jun 21 21:18:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Jun 2004 21:18: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.12.10/8.12.9) with SMTP id i5M4Iugi004851 for ; Mon, 21 Jun 2004 21:18:57 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BcbB0-0001ms-Mi; Tue, 22 Jun 2004 03:38:22 +0100 Message-ID: <40D79B91.2050805@pobox.com> Date: Mon, 21 Jun 2004 22:38:09 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-mm1 2/4] via-velocity: Rx copybreak References: <20040621235615.A7869@electric-eye.fr.zoreil.com> <20040621235808.A9979@electric-eye.fr.zoreil.com> In-Reply-To: <20040621235808.A9979@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6233 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 all 4 patches From c-d.hailfinger.kernel.2004@gmx.net Tue Jun 22 02:52:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 02:52:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5M9q7gi016884 for ; Tue, 22 Jun 2004 02:52:08 -0700 Received: (qmail 18738 invoked by uid 65534); 22 Jun 2004 09:52:02 -0000 Received: from stud222016.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.222.16) by mail.gmx.net (mp015) with SMTP; 22 Jun 2004 11:52:02 +0200 X-Authenticated: #21910825 Message-ID: <40D80118.9010703@gmx.net> Date: Tue, 22 Jun 2004 11:51:20 +0200 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: de, en MIME-Version: 1.0 To: Brian Lazara CC: Manfred Spraul , Christoph Hellwig , Andrew de Quincey , Linux Kernel Mailing List , Netdev , Kalin KOZHUHAROV , Lenny Foner Subject: [PATCH] new device support for forcedeth.c fourth try References: <40D71CBB.4090009@gmx.net> In-Reply-To: <40D71CBB.4090009@gmx.net> Content-Type: multipart/mixed; boundary="------------010003080203050306070601" X-archive-position: 6234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010003080203050306070601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carl-Daniel Hailfinger wrote: > > I have attached a new version of forcedeth. It reduces code duplication > to zero and has mostly transparent handling for different versions of > RX/TX descriptor flags and length. Besides that, the driver should now > be mostly endian safe. And version 15 of the gigabit patch was totally screwed, leading to bogus transmissions (a simple typo caused it). I reread the whole diff line-by-line, fixed incorrect equivalence transformations and I'm quite confident that it is correct now. Known Bug: You will get a "bad: scheduling while atomic" message because of the msleep(500) in PHY reset. Any suggestions how I can avoid this message? Using mdelay(500) has its share of problems too, because it will cause lost time. Please take a look at version 17 of the gigabit patch (Warning: it applies only against 2.6.7-bk4 or later). Regards, Carl-Daniel -- http://www.hailfinger.org/ --------------010003080203050306070601 Content-Type: text/plain; name="forcedeth_gigabit_try17.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="forcedeth_gigabit_try17.txt" ===== drivers/net/forcedeth.c 1.9 vs edited ===== --- 1.9/drivers/net/forcedeth.c 2004-06-17 01:54:01 +02:00 +++ edited/drivers/net/forcedeth.c 2004-06-22 10:23:02 +02:00 @@ -2,9 +2,9 @@ * forcedeth: Ethernet driver for NVIDIA nForce media access controllers. * * Note: This driver is a cleanroom reimplementation based on reverse - * engineered documentation written by Carl-Daniel Hailfinger - * and Andrew de Quincey. It's neither supported nor endorsed - * by NVIDIA Corp. Use at your own risk. + * engineered documentation written by Carl-Daniel Hailfinger + * and Andrew de Quincey. It's neither supported nor endorsed + * by NVIDIA Corp. Use at your own risk. * * NVIDIA, nForce and other NVIDIA marks are trademarks or registered * trademarks of NVIDIA Corporation in the United States and other @@ -12,6 +12,9 @@ * * Copyright (C) 2003 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,18 @@ * 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 * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -80,7 +86,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.25" +#define FORCEDETH_VERSION "0.28" #define DRV_NAME "forcedeth" #include @@ -124,6 +130,7 @@ #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 @@ -133,7 +140,7 @@ #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 @@ -160,7 +167,7 @@ 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, @@ -169,6 +176,8 @@ 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 @@ -182,6 +191,9 @@ NvRegMulticastMaskA = 0xB8, NvRegMulticastMaskB = 0xBC, + NvRegPhyInterface = 0xC0, +#define PHY_RGMII 0x10000000 + NvRegTxRingPhysAddr = 0x100, NvRegRxRingPhysAddr = 0x104, NvRegRingSizes = 0x108, @@ -190,12 +202,12 @@ 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 @@ -214,15 +226,15 @@ 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, @@ -254,34 +266,64 @@ #define NVREG_POWERSTATE_D3 0x0003 }; +/*FIXME big endian */ + 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 @@ -310,10 +352,10 @@ #define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ #define RX_RING 128 -#define TX_RING 16 +#define TX_RING 64 /* limited to 1 packet until we understand NV_TX_LASTPACKET */ -#define TX_LIMIT_STOP 10 -#define TX_LIMIT_START 5 +#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) @@ -323,12 +365,46 @@ #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) +#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. @@ -346,12 +422,15 @@ 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); @@ -371,7 +450,7 @@ 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; }; /* @@ -396,6 +475,37 @@ readl(base); } +static inline u32 nv_descr_getflags(struct ring_desc *prd, u32 v) +{ + return le32_to_cpu(prd->FlagLen) + & ((v == DESC_VER_1) ? FLAG_MASK_V1 : FLAG_MASK_V2); +} + +static inline void nv_descr_setflags(struct ring_desc *prd, u32 v, u32 flags) +{ + prd->FlagLen = (prd->FlagLen + & cpu_to_le32((v == DESC_VER_1) ? LEN_MASK_V1 : LEN_MASK_V2)) + | cpu_to_le32(flags); +} + +static inline void nv_descr_clearflags(struct ring_desc *prd, u32 v) +{ + prd->FlagLen &= cpu_to_le32((v == DESC_VER_1) ? LEN_MASK_V1 : LEN_MASK_V2); +} + +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 inline void nv_descr_setlength(struct ring_desc *prd, u32 v, u32 length) +{ + prd->FlagLen = (prd->FlagLen + & cpu_to_le32((v == DESC_VER_1) ? FLAG_MASK_V1 : FLAG_MASK_V2)) + | cpu_to_le32(length); +} + static int reg_delay(struct net_device *dev, int offset, u32 mask, u32 target, int delay, int delaymax, const char *msg) { @@ -422,24 +532,18 @@ 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; @@ -467,13 +571,125 @@ 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 */ + msleep(500); + + /* must wait till reset is deasserted */ + while (miicontrol & BMCR_RESET) { + udelay(NV_MIIBUSY_DELAY); + miicontrol = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + /* FIXME: 1000 tries seem excessive */ + if (tries++ > 1000) + 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; + unsigned int tries = 0; + + /* 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", dev->name); + 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", dev->name); + return PHY_ERROR; + } + } + else + np->gigabit = 0; + + /* reset the phy */ + if (phy_reset(dev)) { + printk(KERN_INFO "%s: phy reset failed\n", dev->name); + 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", dev->name); + return -1; + } + 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", dev->name); + 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", dev->name); + 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; + } + + /* check auto negotiation is complete */ + mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + while (!(mii_status & BMSR_ANEGCOMPLETE)) { + udelay(NV_MIIBUSY_DELAY); + mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + /* FIXME: 24000 tries seem excessive */ + if (tries++ > 24000) { + printk(KERN_INFO "%s: phy init failed to autoneg.\n", dev->name); + return PHY_TIMEOUT; + } + } + return 0; +} + static void nv_start_rx(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); @@ -498,8 +714,8 @@ 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); @@ -521,8 +737,8 @@ 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); @@ -530,13 +746,14 @@ 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); } @@ -670,10 +887,10 @@ 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); + nv_descr_setlength(&np->rx_ring[nr], np->desc_ver, 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", + nv_descr_setflags(&np->rx_ring[nr], np->desc_ver, NV_RX_AVAIL); + dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", dev->name, refill_rx); refill_rx++; } @@ -704,15 +921,13 @@ 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++) + nv_descr_clearflags(&np->tx_ring[i], np->desc_ver); 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++) + nv_descr_clearflags(&np->rx_ring[i], np->desc_ver); return nv_alloc_rx(dev); } @@ -721,7 +936,7 @@ struct fe_priv *np = get_nvpriv(dev); int i; for (i = 0; i < TX_RING; i++) { - np->tx_ring[i].Flags = 0; + nv_descr_clearflags(&np->tx_ring[i], np->desc_ver); if (np->tx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->tx_dma[i], np->tx_skbuff[i]->len, @@ -738,7 +953,7 @@ struct fe_priv *np = get_nvpriv(dev); int i; for (i = 0; i < RX_RING; i++) { - np->rx_ring[i].Flags = 0; + nv_descr_clearflags(&np->rx_ring[i], np->desc_ver); wmb(); if (np->rx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->rx_dma[i], @@ -770,11 +985,11 @@ 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); + nv_descr_setlength(&np->tx_ring[nr], np->desc_ver, skb->len-1); spin_lock_irq(&np->lock); wmb(); - np->tx_ring[nr].Flags = np->tx_flags; + nv_descr_setflags(&np->tx_ring[nr], np->desc_ver, np->tx_flags); dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n", dev->name, np->next_tx); { @@ -793,7 +1008,7 @@ 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; } @@ -807,26 +1022,39 @@ { struct fe_priv *np = get_nvpriv(dev); - while (np->nic_tx < np->next_tx) { - struct ring_desc *prd; + while (np->nic_tx != np->next_tx) { int i = np->nic_tx % TX_RING; - prd = &np->tx_ring[i]; + u32 Flags = nv_descr_getflags(&np->tx_ring[i], np->desc_ver); 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, @@ -878,7 +1106,6 @@ struct fe_priv *np = get_nvpriv(dev); for (;;) { - struct ring_desc *prd; struct sk_buff *skb; int len; int i; @@ -886,11 +1113,13 @@ break; /* we scanned the whole ring - do not continue */ i = np->cur_rx % RX_RING; - prd = &np->rx_ring[i]; + u32 Flags = nv_descr_getflags(&np->rx_ring[i], np->desc_ver); + 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, */ /* @@ -904,7 +1133,7 @@ { 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); @@ -913,41 +1142,69 @@ 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]; @@ -1043,16 +1300,32 @@ 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; + u32 control_1000, status_1000, phyreg; + + 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)) { + 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) { @@ -1069,11 +1342,35 @@ newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; newdup = 0; } + +set_speed: if (np->duplex != newdup || np->linkspeed != newls) { np->duplex = newdup; np->linkspeed = newls; - return 1; } + + 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 &= ~(0x3); + 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); + return 0; } @@ -1089,26 +1386,28 @@ printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); - if (miival & BMSR_ANEGCOMPLETE) { - nv_update_linkspeed(dev); + if (miistat & NVREG_MIISTAT_LINKCHANGE) { + if (miival & BMSR_LSTATUS) { + nv_update_linkspeed(dev); - if (netif_carrier_ok(dev)) { - nv_stop_rx(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 { - 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)) { - netif_carrier_off(dev); - printk(KERN_INFO "%s: link down.\n", dev->name); - nv_stop_rx(dev); + if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + printk(KERN_INFO "%s: link down.\n", dev->name); + nv_stop_rx(dev); + } + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); } - writel(np->linkspeed, base + NvRegLinkSpeed); - pci_push(base); } } @@ -1136,7 +1435,7 @@ 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); @@ -1158,7 +1457,7 @@ 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 */ @@ -1201,6 +1500,7 @@ struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); int ret, oom, i; + int phy_status = 0; dprintk(KERN_DEBUG "nv_open: begin\n"); @@ -1211,21 +1511,27 @@ 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); @@ -1233,20 +1539,30 @@ 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); + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); + writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus); - /* 5) Find a suitable PHY */ - writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed); + /* 6a) Find a suitable PHY */ for (i = 1; i < 32; i++) { int id1, id2; @@ -1260,13 +1576,13 @@ 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", dev->name, id1, id2, i); np->phyaddr = i; - - spin_lock_irq(&np->lock); - nv_update_linkspeed(dev); - spin_unlock_irq(&np->lock); + np->phy_oui = id1 | id2; break; } @@ -1277,9 +1593,25 @@ goto out_drain; } - /* 6) continue setup */ + /* 6b) Initialize PHY */ + spin_lock_irq(&np->lock); + + /* synchronous init */ + phy_status = phy_init(dev); + if (phy_status == PHY_ERROR) { + printk(KERN_INFO "%s: open: failing due to PHY Init.\n", dev->name); + ret = -EINVAL; + spin_unlock_irq(&np->lock); + goto out_drain; + } + else if (phy_status != PHY_TIMEOUT) + nv_update_linkspeed(dev); + + spin_unlock_irq(&np->lock); + + /* 7) continue setup */ writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), - base + NvRegMisc1); + base + NvRegMisc1); writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus); writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags); writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig); @@ -1291,17 +1623,12 @@ 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); @@ -1309,13 +1636,9 @@ 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); @@ -1337,7 +1660,7 @@ 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 (mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_LSTATUS) { netif_carrier_on(dev); } else { printk("%s: no link during initialization.\n", dev->name); @@ -1448,6 +1771,14 @@ 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) @@ -1507,9 +1838,15 @@ 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) @@ -1570,21 +1907,77 @@ 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, }, { /* 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, + }, + { /* 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, + }, + { /* 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 = 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 = 0x00D6, + .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, @@ -1613,7 +2006,7 @@ 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"); ===== include/linux/pci_ids.h 1.167 vs edited ===== --- 1.167/include/linux/pci_ids.h 2004-06-18 19:06:33 +02:00 +++ edited/include/linux/pci_ids.h 2004-06-21 03:26:39 +02:00 @@ -1061,21 +1061,33 @@ #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_MCP3_AUDIO 0x00da #define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3_IDE 0x00d5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_3 0x00d6 +#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 @@ -1103,6 +1115,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 --------------010003080203050306070601-- From herbert@gondor.apana.org.au Tue Jun 22 03:49:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 03:49:12 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MAmdgi019324 for ; Tue, 22 Jun 2004 03:49: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 1Bciox-0003iH-00; Tue, 22 Jun 2004 20:48:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bcioi-000388-00; Tue, 22 Jun 2004 20:47:53 +1000 From: Herbert Xu To: bernd-schubert@web.de (Bernd Schubert) Subject: Re: 2.6.7 error message (oops) Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <200406212238.49959.bernd-schubert@web.de> 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: Tue, 22 Jun 2004 20:47:53 +1000 X-archive-position: 6235 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 Bernd Schubert wrote: > > I just booted 2.6.7 on one of our systems and see this oops from dmesg: > > eth11: network connection down > Debug: sleeping function called from invalid context at > include/asm/semaphore.h:119 > in_atomic():0, irqs_disabled():1 > [] dump_stack+0x1e/0x20 > [] __might_sleep+0xb0/0xe0 > [] netdev_run_todo+0x2b/0x290 > [] dev_ioctl+0x269/0x300 > [] inet_ioctl+0x8c/0xa0 > [] sock_ioctl+0x138/0x350 > [] sys_ioctl+0x144/0x2d0 > [] syscall_call+0x7/0xb > > The device eth11 is the (ifrename) mapped eth1: > > sk98lin: Network Device Driver v6.23 OK the locking in this driver needs to be reviewed and simplified. In this case it's doing two spin_lock_irqsave() calls in a row on the same flags variable. Does this patch fix your problem? 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 -- Index: drivers/net/sk98lin/skge.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/net/sk98lin/skge.c,v retrieving revision 1.1.1.17 diff -u -r1.1.1.17 skge.c --- drivers/net/sk98lin/skge.c 10 May 2004 09:47:55 -0000 1.1.1.17 +++ drivers/net/sk98lin/skge.c 22 Jun 2004 10:45:23 -0000 @@ -3093,8 +3093,7 @@ SkEventDispatcher(pAC, pAC->IoBase); for (i=0; iGIni.GIMacsFound; i++) { - spin_lock_irqsave( - &pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock); netif_stop_queue(pAC->dev[i]); } @@ -4773,12 +4772,10 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); SkGeStopPort(pAC, IoC, FromPort, SK_STOP_ALL, SK_SOFT_RST); SkGeStopPort(pAC, IoC, ToPort, SK_STOP_ALL, SK_SOFT_RST); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4791,8 +4788,7 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); pAC->ActivePort = ToPort; #if 0 SetQueueSizes(pAC); @@ -4807,8 +4803,7 @@ pAC, pAC->ActivePort, DualNet)) { - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4834,8 +4829,7 @@ SkGePollTxD(pAC, IoC, ToPort, SK_TRUE); ClearAndStartRx(pAC, FromPort); ClearAndStartRx(pAC, ToPort); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); From util@deuroconsult.ro Tue Jun 22 07:10:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 07:10:49 -0700 (PDT) Received: from hosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MEAhgi006703 for ; Tue, 22 Jun 2004 07:10:44 -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 i5MDF6GG001660; Tue, 22 Jun 2004 16:15:06 +0300 Date: Tue, 22 Jun 2004 16:15:06 +0300 (EEST) From: Catalin BOIE X-X-Sender: util@hosting.rdsbv.ro To: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, lartc@mailman.ds9a.nl Subject: [ANNOUNCE] sch_ooo - Out-of-order packet queue discipline Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6236 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 Hello! I like to announce sch_ooo, a new queue discipline that, attached to a class (or a device, as root) reorder the packets that pass by delaying some. Example: tc qdisc add dev eth0 root ooo limit 100 gap 4 wait 1100 This queue will create a pfifo with limit 100 and will delay every 4th packet with 1100ms. An stream of 6 packets like this: 1 2 3 4 5 6, generated by ping will be reordered like this: 1 2 3 5 4 6. Example for a ping: PING mp3 (x.y.0.2) 56(84) bytes of data. 64 bytes from X (x.y.0.2): icmp_seq=1 ttl=64 time=69.6 ms 64 bytes from X (x.y.0.2): icmp_seq=2 ttl=64 time=68.7 ms 64 bytes from X (x.y.0.2): icmp_seq=3 ttl=64 time=71.8 ms 64 bytes from X (x.y.0.2): icmp_seq=5 ttl=64 time=70.1 ms 64 bytes from X (x.y.0.2): icmp_seq=4 ttl=64 time=1145 ms 64 bytes from X (x.y.0.2): icmp_seq=6 ttl=64 time=75.6 ms You can see that seq 4 and 5 are reordered because seq 4 was delayed with 1100ms. This is for 2.6, but it's trivial to port to 2.4 if needed. If you think it worth, please include it. Any comments are appreciated. Thanks! P.S. The homepage is at http://kernel.umbrella.ro/ P.P.S. The license is GPL. --- linux.orig/net/sched/Kconfig 2004-06-16 08:19:52.000000000 +0300 +++ linux/net/sched/Kconfig 2004-06-22 15:03:11.000000000 +0300 @@ -175,6 +175,17 @@ config NET_SCH_DELAY To compile this driver as a module, choose M here: the module will be called sch_delay. +config NET_SCH_OOO + tristate "Out-of-order qdisc discipline" + depends on NET_SCHED + help + Say Y if you want to simulate out-of-order packets by delaying + some of them. This qdisc is useful if you develop + protocols or network monitoring applications. + + To compile this driver as a module, choose M here: the module + will be called sch_ooo. + config NET_SCH_INGRESS tristate "Ingress Qdisc" depends on NET_SCHED && NETFILTER --- linux.orig/net/sched/Makefile 2004-06-16 08:19:23.000000000 +0300 +++ linux/net/sched/Makefile 2004-06-22 15:03:25.000000000 +0300 @@ -23,6 +23,7 @@ obj-$(CONFIG_NET_SCH_TEQL) += sch_teql.o obj-$(CONFIG_NET_SCH_PRIO) += sch_prio.o obj-$(CONFIG_NET_SCH_ATM) += sch_atm.o obj-$(CONFIG_NET_SCH_DELAY) += sch_delay.o +obj-$(CONFIG_NET_SCH_OOO) += sch_ooo.o obj-$(CONFIG_NET_CLS_U32) += cls_u32.o obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o obj-$(CONFIG_NET_CLS_FW) += cls_fw.o --- linux.orig/net/sched/sch_ooo.c 1970-01-01 02:00:00.000000000 +0200 +++ linux/net/sched/sch_ooo.c 2004-06-22 16:08:18.000000000 +0300 @@ -0,0 +1,301 @@ +/* + * net/sched/sch_ooo.c Out-of-order qdisc discipline routines. + * + * 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: Catalin(ux aka Dino) BOIE, + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + +#define MODULE_NAME "sch_ooo v0.1" + +#if 0 +#define DPRINTK(format,args...) printk(KERN_DEBUG MODULE_NAME ": " format, ##args) +#else +#define DPRINTK(format,args...) +#endif + + +/* global variables */ + +/* qdisc internal data */ +struct ooo_sched_data { + __u32 limit; /* in packets */ + __u32 gap; /* gap + 1 between ooo packets */ + __u32 wait; /* how much ms to wait before release a marked ooo */ + /* 0 = disable */ + /* private data */ + __u32 counter; /* keep track of frequncy */ + struct sk_buff_head qooo; + struct timer_list timer; + __u32 tokens; +}; + +static void ooo_timer(unsigned long arg) +{ + struct Qdisc *sch = (struct Qdisc *)arg; + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + + DPRINTK("timer: Add a token and sched dev!\n"); + + /* add a token */ + q->tokens++; + + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); +} + +static int ooo_init(struct Qdisc *sch, struct rtattr *opt) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + + memset (q, 0, sizeof(struct ooo_sched_data)); + + sch->stats.lock = &sch->dev->queue_lock; + + /* init timer */ + init_timer(&q->timer); + q->timer.function = ooo_timer; + q->timer.data = (unsigned long) sch; + + /* init ooo queue */ + skb_queue_head_init(&q->qooo); + + q->counter = 0; + q->tokens = 0; + + if (!opt) { + q->limit = sch->dev->tx_queue_len; + q->gap = 0; + q->wait = 0; + } else { + struct tc_ooo_qopt *ctl = RTA_DATA(opt); + + if (opt->rta_len < RTA_LENGTH(sizeof(*ctl))) + return -EINVAL; + + q->limit = ctl->limit; + q->gap = ctl->gap; + q->wait = ctl->wait; + } + + return 0; +} + +static int ooo_enqueue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + + q->counter ++; + + DPRINTK("enqueue: Q%X:%X gap=%d counter=%d wait=%d len=%d\n", + sch->handle >> 16, sch->handle & 0xffff, + q->gap, q->counter, q->wait, skb->len); + + /* do we have room? */ + if (sch->q.qlen < q->limit) { + __skb_queue_tail(&sch->q, skb); /* autoinc qlen */ + sch->stats.bytes += skb->len; + sch->stats.packets++; + + return NET_XMIT_SUCCESS; + } + + sch->stats.drops++; + kfree_skb(skb); + + return NET_XMIT_DROP; +} + +static struct sk_buff *ooo_dequeue(struct Qdisc *sch) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + struct sk_buff *skb = NULL; + long howmuch; + + /* time to delay a packet? */ + if ((q->gap > 0) && (q->counter >= q->gap)) { + struct sk_buff *skb2; + + DPRINTK("dequeue: move head packet from primary q to tail of ooo queue\n"); + + skb2 = __skb_dequeue(&sch->q); /* auto dec qlen */ + if (!skb2) { + DPRINTK("dequeue called with queue empty!\n"); + return NULL; + } + /* put back qlen */ + sch->q.qlen++; + + __skb_queue_tail(&q->qooo, skb2); /* auto inc qlen */ + + /* reset counter */ + q->counter = 0; + + /* add timer */ + howmuch = jiffies + PSCHED_US2JIFFIE(q->wait * 1000); + DPRINTK("Add timer jiffies=%ld timer=%ld\n", jiffies, howmuch); + mod_timer(&q->timer, howmuch); + } + + /* Try to dequeue from ooo queue if we have enough tokens */ + if (q->tokens > 0) { + skb = __skb_dequeue(&q->qooo); + if (skb) { + q->tokens--; + sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + } + + DPRINTK("dequeue: from qooo queue [%p]\n", skb); + } + + if (!skb) { + skb = __skb_dequeue(&sch->q); + DPRINTK("dequeue: from main queue [%p]\n", skb); + } + + return skb; +} + +static int ooo_requeue(struct sk_buff *skb, struct Qdisc *sch) +{ + + __skb_queue_head(&sch->q, skb); + + return NET_XMIT_SUCCESS; +} + +static unsigned int ooo_drop(struct Qdisc *sch) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + struct sk_buff *skb; + + skb = __skb_dequeue_tail(&sch->q); + if (!skb) + skb = __skb_dequeue_tail (&q->qooo); + + if (skb) { + unsigned int len = skb->len; + + sch->stats.backlog -= len; + kfree_skb(skb); + sch->q.qlen --; + return len; + } + + return 0; +} + +static void ooo_reset(struct Qdisc *sch) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + + del_timer(&q->timer); + skb_queue_purge(&q->qooo); + skb_queue_purge(&sch->q); + sch->flags &= ~TCQ_F_THROTTLED; +} + +static void ooo_destroy(struct Qdisc *sch) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + + del_timer(&q->timer); + skb_queue_purge(&q->qooo); + skb_queue_purge(&sch->q); +} + +static int ooo_dump(struct Qdisc *sch, struct sk_buff *skb) +{ + struct ooo_sched_data *q = (struct ooo_sched_data *)sch->data; + struct tc_ooo_qopt opt; + unsigned char *b = skb->tail; + + opt.limit = q->limit; + opt.gap = q->gap; + opt.wait = q->wait; + RTA_PUT(skb, TCA_OPTIONS, sizeof(opt), &opt); + + return skb->len; + + rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static struct Qdisc_ops ooo_qdisc_ops = { + .next = NULL, + .cl_ops = NULL, + .id = "ooo", + .priv_size = sizeof(struct ooo_sched_data), + .enqueue = ooo_enqueue, + .dequeue = ooo_dequeue, + .requeue = ooo_requeue, + .drop = ooo_drop, + .init = ooo_init, + .reset = ooo_reset, + .destroy = ooo_destroy, + .change = ooo_init, + .dump = ooo_dump, + .owner = THIS_MODULE, +}; + +static int __init init_ooo(void) +{ + int ret; + + printk(KERN_DEBUG "%s: (C)opyright Catalin(ux aka Dino) BOIE 2003-2004\n", + MODULE_NAME); + + ret = register_qdisc(&ooo_qdisc_ops); + if (ret != 0) { + printk(KERN_DEBUG "%s: cannot register qdisc ooo. Sorry!\n", + MODULE_NAME); + return -ENOMEM; + } + + return 0; +} + +static void __exit exit_ooo(void) +{ + int ret; + + printk(KERN_DEBUG "%s: Goodbye!\n", MODULE_NAME); + + ret = unregister_qdisc(&ooo_qdisc_ops); + if (ret != 0) { + printk(KERN_DEBUG "%s: Cannot unregister qdisc ooo. Sorry!\n", + MODULE_NAME); + } +} + +module_init(init_ooo); +module_exit(exit_ooo); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Catalin(ux) BOIE - "); +MODULE_DESCRIPTION("sch_ooo - Produce ooo (out-of-order) packets"); --- linux.orig/include/linux/pkt_sched.h 2004-06-16 08:19:43.000000000 +0300 +++ linux/include/linux/pkt_sched.h 2004-06-22 15:16:44.000000000 +0300 @@ -438,4 +438,12 @@ struct tc_dly_qopt __u32 latency; __u32 limit; }; + +/* sch_ooo section */ +struct tc_ooo_qopt +{ + __u32 limit; + __u32 gap; + __u32 wait; +}; #endif --- Catalin(ux aka Dino) BOIE catab at umbrella dot ro From cfriesen@nortelnetworks.com Tue Jun 22 07:54:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 07:54:43 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MEscgi007875 for ; Tue, 22 Jun 2004 07:54:38 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5MErOJ27343; Tue, 22 Jun 2004 10:53:24 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALS0F4P; Tue, 22 Jun 2004 10:53:25 -0400 Message-ID: <40D847E3.2080109@nortelnetworks.com> Date: Tue, 22 Jun 2004 10:53:23 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , kernel@nn7.de, linux-kernel@vger.kernel.org, benh@kernel.crashing.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops References: <20040621141144.119be627.davem@redhat.com> In-Reply-To: <20040621141144.119be627.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Mon, 21 Jun 2004 23:03:16 +1000 > Herbert Xu wrote: > > > On Mon, Jun 21, 2004 at 10:33:50PM +1000, Herbert Xu wrote: > > > > > > Does this patch fix your problems? > > > > Oops, I had a thinko about min vs. max. I've also decided to make the > > bigger MTU useful by adjusting the arguments to skb_put() as well. > > Please try this one instead. > > Applied, thanks Herbert. Just a quick question. Does the sungem chip support jumbo frames? I'd like to use MTU of 9000 to make large local transfers more efficient, but it didn't seem to work last time I checked. Thanks, Chris From jgarzik@pobox.com Tue Jun 22 08:29:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 08:30: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.12.10/8.12.9) with SMTP id i5MFTvgi012325 for ; Tue, 22 Jun 2004 08:29:57 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BbQV4-0004U9-Ly; Fri, 18 Jun 2004 22:02:15 +0100 Message-ID: <40D3584A.9010009@pobox.com> Date: Fri, 18 Jun 2004 17:02:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-rc3-mm2 2/5] via-velocity: uniformize use of OWNED_BY_NIC References: <20040618221014.A15640@electric-eye.fr.zoreil.com> <20040618221142.A20210@electric-eye.fr.zoreil.com> In-Reply-To: <20040618221142.A20210@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6238 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 Francois Romieu wrote: > Introduce velocity_give_rx_desc() to uniformize the use of OWNED_BY_NIC > through the driver. > > diff -puN drivers/net/via-velocity.c~via-velocity-30 drivers/net/via-velocity.c > --- linux-2.6.7-rc3/drivers/net/via-velocity.c~via-velocity-30 2004-06-18 21:34:14.000000000 +0200 > +++ linux-2.6.7-rc3-fr/drivers/net/via-velocity.c 2004-06-18 21:34:14.000000000 +0200 > @@ -465,6 +465,12 @@ static void velocity_init_cam_filter(str > } > } > > +static inline void velocity_give_rx_desc(struct rx_desc *rd) > +{ > + *(u32 *)&rd->rdesc0 = 0; > + rd->rdesc0.owner = cpu_to_le32(OWNED_BY_NIC); > +} The patch itself is OK, and I will merge, but I wonder: isn't a wmb() needed perhaps? Jeff From shemminger@osdl.org Tue Jun 22 08:46:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 08:46:17 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MFkFgi012952 for ; Tue, 22 Jun 2004 08:46:15 -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 i5MFk7r11109; Tue, 22 Jun 2004 08:46:07 -0700 Date: Tue, 22 Jun 2004 08:46:07 -0700 From: Stephen Hemminger To: Catalin BOIE Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, lartc@mailman.ds9a.nl Subject: Re: [LARTC] [ANNOUNCE] sch_ooo - Out-of-order packet queue discipline Message-Id: <20040622084607.4996569f@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: 6239 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 Maybe the delay and ooo scheduler should be merged, the both do sort of the same thing. From benh@kernel.crashing.org Tue Jun 22 09:10:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 09:10:24 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MGALgi013892 for ; Tue, 22 Jun 2004 09:10:21 -0700 Received: from localhost (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id i5MG3iHR024314; Tue, 22 Jun 2004 11:03:44 -0500 Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops From: Benjamin Herrenschmidt To: Jeff Garzik Cc: Chris Friesen , "David S. Miller" , Herbert Xu , kernel@nn7.de, Linux Kernel list , netdev@oss.sgi.com In-Reply-To: <40D84A9B.8010503@pobox.com> References: <20040621141144.119be627.davem@redhat.com> <40D847E3.2080109@nortelnetworks.com> <40D84A9B.8010503@pobox.com> Content-Type: text/plain Message-Id: <1087920212.22687.50.camel@gaston> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 22 Jun 2004 11:03:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 6240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: benh@kernel.crashing.org Precedence: bulk X-list: netdev On Tue, 2004-06-22 at 10:04, Jeff Garzik wrote: > Chris Friesen wrote: > > Just a quick question. Does the sungem chip support jumbo frames? I'd > > like to use MTU of 9000 to make large local transfers more efficient, > > but it didn't seem to work last time I checked. > > > Are you 100% certain you configured the other side to support jumbo? > > Jumbo frames are non-standard, and sometimes require configuring MTU on > the switch or remote network card (if directly connected). Well, it's not enabled in the driver I think, or at least it wasn't last time I looked. Dave told me the chip fifo's are too small to do anything useful with jumbo frames. Ben. From shemminger@osdl.org Tue Jun 22 10:50:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 10:50:15 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MHoCgi016785 for ; Tue, 22 Jun 2004 10:50:12 -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 i5MHnrr02766; Tue, 22 Jun 2004 10:49:53 -0700 Date: Tue, 22 Jun 2004 10:49:53 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] skfddi - cleanup local and dead functions Message-Id: <20040622104953.10a5930e@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: 6241 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 Cleanup the SK Fddi driver a little more. Mark some functions as static, and eliminate (or comment out) some that are defined but never used. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/skfp/fplustm.c b/drivers/net/skfp/fplustm.c --- a/drivers/net/skfp/fplustm.c 2004-06-22 10:47:00 -07:00 +++ b/drivers/net/skfp/fplustm.c 2004-06-22 10:47:00 -07:00 @@ -141,16 +141,17 @@ /* * write long value into buffer memory over memory data register (MDR), */ -void write_mdr(struct s_smc *smc, u_long val) +static void write_mdr(struct s_smc *smc, u_long val) { CHECK_NPP() ; MDRW(val) ; } +#if 0 /* * read long value from buffer memory over memory data register (MDR), */ -u_long read_mdr(struct s_smc *smc, unsigned int addr) +static u_long read_mdr(struct s_smc *smc, unsigned int addr) { long p ; CHECK_NPP() ; @@ -164,6 +165,8 @@ p += (u_long)inpw(FM_A(FM_MDRL)) ; return(p) ; } +#endif + /* * clear buffer memory */ @@ -529,7 +532,7 @@ outpw(FM_A(FM_RPXSF),0) ; } -void formac_rcv_restart(struct s_smc *smc) +static void formac_rcv_restart(struct s_smc *smc) { /* enable receive function */ SETMASK(FM_A(FM_MDREG1),smc->hw.fp.rx_mode,FM_ADDRX) ; @@ -1017,25 +1020,6 @@ } /*-------------------------- interface functions ----------------------------*/ -/* - * control ODL output - */ -void sm_pm_control(struct s_smc *smc, int mode) -{ - SK_UNUSED(smc) ; - - /* - * if PCM logic has set LS_REQUEST = Transmit QUIET Line State - * /FOTOFF signal turn activ -> ODL disable - */ - switch(mode) { - case PM_TRANSMIT_DISABLE : - break ; - case PM_TRANSMIT_ENABLE : - break ; - } -} - /* * control MAC layer (called by RMT) */ From util@deuroconsult.ro Tue Jun 22 10:52:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 10:52:13 -0700 (PDT) Received: from hosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MHq8gi017037 for ; Tue, 22 Jun 2004 10:52:09 -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 i5MHq1sd017294; Tue, 22 Jun 2004 20:52:01 +0300 Date: Tue, 22 Jun 2004 20:52:01 +0300 (EEST) From: Catalin BOIE X-X-Sender: util@hosting.rdsbv.ro To: Stephen Hemminger cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, lartc@mailman.ds9a.nl Subject: Re: [LARTC] [ANNOUNCE] sch_ooo - Out-of-order packet queue discipline In-Reply-To: <20040622084607.4996569f@dell_ss3.pdx.osdl.net> Message-ID: References: <20040622084607.4996569f@dell_ss3.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6242 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 On Tue, 22 Jun 2004, Stephen Hemminger wrote: > Maybe the delay and ooo scheduler should be merged, the both do sort of > the same thing. Yes, it's true. I can work on a patch if you want. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From shemminger@osdl.org Tue Jun 22 10:52:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 10:52:27 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MHqPgi017136 for ; Tue, 22 Jun 2004 10:52:25 -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 i5MHpkr03009; Tue, 22 Jun 2004 10:51:47 -0700 Date: Tue, 22 Jun 2004 10:51:46 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] skfddi - fix warning Message-Id: <20040622105146.56e92d80@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: 6243 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 The conversion to ANSI, caused a warning because the mulitcast code needs a cast. dmi->dmi_addr is a u8 array, and fddi_addr is just a wrapper around a u8 array. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c --- a/drivers/net/skfp/skfddi.c 2004-06-22 10:47:41 -07:00 +++ b/drivers/net/skfp/skfddi.c 2004-06-22 10:47:41 -07:00 @@ -909,7 +909,10 @@ dmi = dev->mc_list; for (i = 0; i < dev->mc_count; i++) { - mac_add_multicast(smc, dmi->dmi_addr, 1); + mac_add_multicast(smc, + (struct fddi_addr *)dmi->dmi_addr, + 1); + PRINTK(KERN_INFO "ENABLE MC ADDRESS:"); PRINTK(" %02x %02x %02x ", dmi->dmi_addr[0], From P@draigBrady.com Tue Jun 22 11:04:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 11:04:16 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MI44gi017973 for ; Tue, 22 Jun 2004 11:04:05 -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 i5MI41OC055002 for ; Tue, 22 Jun 2004 19:04:02 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40D87491.9040709@draigBrady.com> Date: Tue, 22 Jun 2004 19:04:01 +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: netdev@oss.sgi.com Subject: e1000 jumbo problems Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i5MI41OC055002 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5MI44gi017973 X-archive-position: 6244 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 Summary, machine locks up when receiving jumbo frames. machine = 2 P4 CPUs with hyperthreading, so 4 logical CPUs, 512MiB RAM I'm using linux 2.4.20 with e1000-5.2.52 in NAPI mode (with the fix applied in -k3 to fix NAPI/ifdown crash) I was also seeing the same problem with 5.2.30.1 I'm also using IRQ affinity: CPU0 CPU1 CPU2 CPU3 24: 7096026 0 0 0 IO-APIC-level 25: 2 0 61115 0 IO-APIC-level The problem seems independent of mtu size, and I've set MTUs of 4000, 9000, 16110 with the same problem. When sending packets of up to 2K in size on one interface at a rate of about 5Kpps there is no problem. But once I go above that packet size I can get the machine to hang up within a minute or two. Note the interface is in promiscous mode and hangs whether the packets are just dropped by the driver or processed (by a userspace program). There are no oops at all, the system just freezes (numlock etc. is dead also). Note if packets are sent in between 2K and 2.5K in size, there seems to be driver structure corruption rather than a system freeze. In this state the interface bounces every minute or so. Also this is the ethtool -S output (which changes a little for each run even though no packets are being received?): NIC statistics: rx_packets: 153018775 tx_packets: 152565456 rx_bytes: 1093747991 tx_bytes: 152565456 rx_errors: 1067958192 tx_errors: 305130916 rx_dropped: 152565456 tx_dropped: 0 multicast: 152918771 collisions: 152565454 rx_length_errors: 152565456 rx_over_errors: 0 rx_crc_errors: 152565460 rx_frame_errors: 152565454 rx_fifo_errors: 152565458 rx_missed_errors: 152565458 tx_aborted_errors: 152565458 tx_carrier_errors: 152565454 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 152565458 tx_abort_late_coll: 10106210612946 tx_deferred_ok: 10110505580240 tx_single_coll_ok: 10106210612946 tx_multi_coll_ok: 10106210612946 rx_long_length_errors: 10106210612946 rx_short_length_errors: 10110505580240 rx_align_errors: 10114800547534 tx_tcp_seg_good: 10114800547534 tx_tcp_seg_failed: 10114800547534 rx_flow_control_xon: 10110505580240 rx_flow_control_xoff: 10110505580240 tx_flow_control_xon: 10110505580240 tx_flow_control_xoff: 10110505580240 rx_csum_offload_good: 0 rx_csum_offload_errors: 0 I also noticed driver structure corruption exactly like above when transmitting packets in the 1500 -> 2000 bytes range. Another related issue, is that the driver uses 4096KiB buffers for MTUs in the 1500 -> 2000 range which seems a bit silly. Any particular reason for that? Also is there a public dev tree available for the e1000 driver? cheers, Pádraig. From shemminger@osdl.org Tue Jun 22 11:32:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 11:32:45 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MIWdgi018871 for ; Tue, 22 Jun 2004 11:32: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 i5MIUqr10160; Tue, 22 Jun 2004 11:30:52 -0700 Date: Tue, 22 Jun 2004 11:30:52 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] get rid of __OPTIMIZE__ requirement in net drivers Message-Id: <20040622113052.1ef2cb7b@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: 6245 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 Several network drivers have checks that they are only built with -O. This breaks checking with sparse and other tools, and seems like a holdover from when drivers were built out of tree and the kernel build system was less stable. This patch gets rid of these. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/3c59x.c b/drivers/net/3c59x.c --- a/drivers/net/3c59x.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/3c59x.c 2004-06-22 11:28:15 -07:00 @@ -238,12 +238,6 @@ static int vortex_debug = 1; #endif -#ifndef __OPTIMIZE__ -#error You must compile this file with the correct options! -#error See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/eepro100.c b/drivers/net/eepro100.c --- a/drivers/net/eepro100.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/eepro100.c 2004-06-22 11:28:15 -07:00 @@ -87,12 +87,6 @@ /* Size of an pre-allocated Rx buffer: + slack.*/ #define PKT_BUF_SZ 1536 -#if !defined(__OPTIMIZE__) || !defined(__KERNEL__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/epic100.c b/drivers/net/epic100.c --- a/drivers/net/epic100.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/epic100.c 2004-06-22 11:28:15 -07:00 @@ -116,12 +116,6 @@ #define TX_FIFO_THRESH 256 #define RX_FIFO_THRESH 1 /* 0-3, 0==32, 64,96, or 3==128 bytes */ -#if !defined(__OPTIMIZE__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/natsemi.c b/drivers/net/natsemi.c --- a/drivers/net/natsemi.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/natsemi.c 2004-06-22 11:28:15 -07:00 @@ -139,12 +139,6 @@ * NAPI */ -#if !defined(__OPTIMIZE__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c --- a/drivers/net/sb1250-mac.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/sb1250-mac.c 2004-06-22 11:28:15 -07:00 @@ -55,12 +55,6 @@ /* Time in jiffies before concluding the transmitter is hung. */ #define TX_TIMEOUT (2*HZ) -#if !defined(__OPTIMIZE__) || !defined(__KERNEL__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/sk98lin/h/skdrv1st.h b/drivers/net/sk98lin/h/skdrv1st.h --- a/drivers/net/sk98lin/h/skdrv1st.h 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/sk98lin/h/skdrv1st.h 2004-06-22 11:28:15 -07:00 @@ -58,12 +58,6 @@ #define SK_ADDR_EQUAL(a1,a2) (!memcmp(a1,a2,6)) -#if !defined(__OPTIMIZE__) || !defined(__KERNEL__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/sundance.c b/drivers/net/sundance.c --- a/drivers/net/sundance.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/sundance.c 2004-06-22 11:28:15 -07:00 @@ -148,15 +148,6 @@ #define TX_TIMEOUT (4*HZ) #define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.*/ -#ifndef __KERNEL__ -#define __KERNEL__ -#endif -#if !defined(__OPTIMIZE__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - /* Include files, designed to support most kernel versions 2.0.0 and later. */ #include #include diff -Nru a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c --- a/drivers/net/tulip/winbond-840.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/tulip/winbond-840.c 2004-06-22 11:28:15 -07:00 @@ -111,15 +111,6 @@ #define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.*/ -#ifndef __KERNEL__ -#define __KERNEL__ -#endif -#if !defined(__OPTIMIZE__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - /* Include files, designed to support most kernel versions 2.0.0 and later. */ #include #include diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/typhoon.c 2004-06-22 11:28:15 -07:00 @@ -90,12 +90,6 @@ #define PFX DRV_MODULE_NAME ": " #define ERR_PFX KERN_ERR PFX -#if !defined(__OPTIMIZE__) || !defined(__KERNEL__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/via-rhine.c 2004-06-22 11:28:15 -07:00 @@ -183,12 +183,6 @@ #define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.*/ -#if !defined(__OPTIMIZE__) || !defined(__KERNEL__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include diff -Nru a/drivers/net/yellowfin.c b/drivers/net/yellowfin.c --- a/drivers/net/yellowfin.c 2004-06-22 11:28:15 -07:00 +++ b/drivers/net/yellowfin.c 2004-06-22 11:28:15 -07:00 @@ -108,12 +108,6 @@ #define yellowfin_debug debug -#if !defined(__OPTIMIZE__) -#warning You must compile this file with the correct options! -#warning See the last lines of the source file. -#error You must compile this driver with "-O". -#endif - #include #include #include From davem@redhat.com Tue Jun 22 12:36:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 12:36:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MJa0gi024301 for ; Tue, 22 Jun 2004 12:36:01 -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 i5MJZde1014136; Tue, 22 Jun 2004 15:35:39 -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 i5MJZc010984; Tue, 22 Jun 2004 15:35:38 -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 i5MJZHGs003594; Tue, 22 Jun 2004 15:35:17 -0400 Date: Tue, 22 Jun 2004 12:35:23 -0700 From: "David S. Miller" To: Chris Friesen Cc: herbert@gondor.apana.org.au, kernel@nn7.de, linux-kernel@vger.kernel.org, benh@kernel.crashing.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: sungem - ifconfig eth0 mtu 1300 -> oops Message-Id: <20040622123523.28fca55a.davem@redhat.com> In-Reply-To: <40D847E3.2080109@nortelnetworks.com> References: <20040621141144.119be627.davem@redhat.com> <40D847E3.2080109@nortelnetworks.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: 6246 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 Tue, 22 Jun 2004 10:53:23 -0400 Chris Friesen wrote: > Just a quick question. Does the sungem chip support jumbo frames? Nope, not at all. From davem@redhat.com Tue Jun 22 12:39:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 12:39:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MJdogi024650 for ; Tue, 22 Jun 2004 12:39:50 -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 i5MJdke1015288; Tue, 22 Jun 2004 15:39: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 i5MJdj012705; Tue, 22 Jun 2004 15:39:45 -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 i5MJdOvj006571; Tue, 22 Jun 2004 15:39:24 -0400 Date: Tue, 22 Jun 2004 12:39:31 -0700 From: "David S. Miller" To: Arthur Kepner Cc: akpm@osdl.org, netdev@oss.sgi.com, chrisw@osdl.org, gillb4@telusplanet.net Subject: Re: [PATCH] preempt count regression w/ lockless loopback patch Message-Id: <20040622123931.50d5ac05.davem@redhat.com> In-Reply-To: References: <200406210510.i5L5A340018849@hera.kernel.org> <20040621035702.6114bdbe.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: 6247 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 Tue, 22 Jun 2004 09:24:40 -0700 Arthur Kepner wrote: > I made one small change in get_stats() and tested with a preemptible > kernel on a 32p system. Looks good. The tested patch is attached. Can you instead give a patch relative to Andrew's? His is applied already and in fact pushed into Linus's tree. From akpm@osdl.org Tue Jun 22 12:41:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 12:41:34 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MJfWgi024990 for ; Tue, 22 Jun 2004 12:41:32 -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 i5MJfQr11541; Tue, 22 Jun 2004 12:41:26 -0700 Date: Tue, 22 Jun 2004 12:40:31 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: simon@thekelleys.org.uk Subject: Fw: Oops in dev_get_by_index. Message-Id: <20040622124031.15d9315f.akpm@osdl.org> 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: 6248 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 Begin forwarded message: Date: Tue, 22 Jun 2004 19:57:02 +0100 From: Simon Kelley To: LKML Cc: simon@thekelleys.org.uk Subject: Oops in dev_get_by_index. I've received a bug-report that dnsmasq (http://www.thekelleys.org.uk/dnsmasq) is provoking a kernel Oops and I'm posting everything I know about it here in the hope that someone who knows the relevant code will be able to see instantly what the problem is. The Oops looks like this: CPU: 0 EIP: 0060:[<02237d52>] Not tainted EFLAGS: 00010202 (2.6.6-1.435) EIP is at __dev_get_by_index+0x14/0x2b eax: 10a64134 ebx: 02cabef8 ecx: 00000006 edx: 00000000 esi: 075ab000 edi: 00008910 ebp: fef735e0 esp: 02cabef0 ds: 007b es: 007b ss: 0068 Process dnsmasq (pid: 7524, threadinfo=02cab000 task=0e3f7270) Stack: 02238e9a 00000000 00000000 00000000 080570eb 0977bdd0 00000006 fef73608 00ae007e 00b44ffc fef735e0 075ab000 00008910 02266641 02239733 fef735e0 00000008 00000000 11566b80 09774436 000001da 02cabf70 0000000c 0000000c Call Trace: [<02238e9a>] dev_ifname+0x30/0x66 [<02266641>] udp_ioctl+0x0/0x6e [<02239733>] dev_ioctl+0x83/0x283 [<02266641>] udp_ioctl+0x0/0x6e [<0226c323>] inet_ioctl+0x6e/0x73 [<02232936>] sock_ioctl+0x26d/0x285 [<0214f7f6>] sys_ioctl+0x1f2/0x224 Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea This is the kernel part of the ioctl in dnsmasq-2.8/src/forward.c which does ifr.ifr_ifindex = if_index; ioctl(fd, SIOCGIFNAME, &ifr) were the fd is a UDP socket which has had recvmsg called to get the datagram and IP_PKTINFO auxiliary data from which the if_index is derived. The kernel version in question is 2.6.6-1.435 from Fedora. There's a possibility if IPv6 involvement. The kernel has IPv6 loaded and the network interfaces have IPv6 addresses. Under those circumstances dnsmasq will bind the IPv6 addresses automatically. I have no way of telling if the Oops was as a result of receiving an IPv6 datagram, but it is unlikely since IPv6 is not in active use. The Oops happens rarely: there is no known way to reproduce it on demand. That's all the information I have: can anybody spot a problem? Cheers, Simon. - 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 jgarzik@pobox.com Tue Jun 22 12:53:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 12:53:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MJrRgi025501 for ; Tue, 22 Jun 2004 12:53:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BcrKg-0004La-Hs; Tue, 22 Jun 2004 20:53:26 +0100 Message-ID: <40D88E02.1030701@pobox.com> Date: Tue, 22 Jun 2004 15:52:34 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] get rid of __OPTIMIZE__ requirement in net drivers References: <20040622113052.1ef2cb7b@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622113052.1ef2cb7b@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6249 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 Stephen Hemminger wrote: > Several network drivers have checks that they are only built with -O. > This breaks checking with sparse and other tools, and seems like a holdover from > when drivers were built out of tree and the kernel build system was less stable. > This patch gets rid of these. Guess is 50% correct... holdover from people compiling the drivers out-of-tree using a single shell command (that runs gcc), found at the bottom of the driver. No objection to the patch, though, just saying :) I'll apply... Jeff From davem@redhat.com Tue Jun 22 13:15:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 13:15:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MKFIgi026220 for ; Tue, 22 Jun 2004 13:15:19 -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 i5MKF7e1024574; Tue, 22 Jun 2004 16:15:07 -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 i5MKF7025581; Tue, 22 Jun 2004 16:15:07 -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 i5MKEjls030471; Tue, 22 Jun 2004 16:14:46 -0400 Date: Tue, 22 Jun 2004 13:14:51 -0700 From: "David S. Miller" To: Catalin BOIE Cc: shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, lartc@mailman.ds9a.nl Subject: Re: [LARTC] [ANNOUNCE] sch_ooo - Out-of-order packet queue discipline Message-Id: <20040622131451.3a6a5190.davem@redhat.com> In-Reply-To: References: <20040622084607.4996569f@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: 6250 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 Tue, 22 Jun 2004 20:52:01 +0300 (EEST) Catalin BOIE wrote: > On Tue, 22 Jun 2004, Stephen Hemminger wrote: > > > Maybe the delay and ooo scheduler should be merged, the both do sort of > > the same thing. > > Yes, it's true. > I can work on a patch if you want. You should, that would be great. From akepner@sgi.com Tue Jun 22 13:51:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 13:51:50 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MKpmgi032226 for ; Tue, 22 Jun 2004 13:51:48 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5MKpYiv019588 for ; Tue, 22 Jun 2004 15:51:34 -0500 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i5MKp3Ce18518297; Tue, 22 Jun 2004 13:51:18 -0700 (PDT) Date: Tue, 22 Jun 2004 13:46:07 -0700 From: Arthur Kepner X-X-Sender: akepner@neteng.engr.sgi.com To: "David S. Miller" cc: akpm@osdl.org, netdev@oss.sgi.com, chrisw@osdl.org, gillb4@telusplanet.net Subject: Re: [PATCH] preempt count regression w/ lockless loopback patch In-Reply-To: <20040622123931.50d5ac05.davem@redhat.com> Message-ID: References: <200406210510.i5L5A340018849@hera.kernel.org> <20040621035702.6114bdbe.akpm@osdl.org> <20040622123931.50d5ac05.davem@redhat.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1072017398-688446164-1087937167=:1357620" X-archive-position: 6252 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 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. ---1072017398-688446164-1087937167=:1357620 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Jun 2004, David S. Miller wrote: > .... > Can you instead give a patch relative to Andrew's? His is > applied already and in fact pushed into Linus's tree. > Yes. It is in the attachment. -- Arthur ---1072017398-688446164-1087937167=:1357620 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch.rel_akpm" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patch relative to akpm Content-Disposition: attachment; filename="patch.rel_akpm" LS0tIGxpbnV4LmFrcG0vZHJpdmVycy9uZXQvbG9vcGJhY2suYwkyMDA0LTA2 LTIyIDEzOjM1OjEzLjAwMDAwMDAwMCAtMDcwMA0KKysrIGxpbnV4L2RyaXZl cnMvbmV0L2xvb3BiYWNrLmMJMjAwNC0wNi0yMiAxMzo0MjoyNy4wMDAwMDAw MDAgLTA3MDANCkBAIC0xNzMsMTIgKzE3MywxMSBAQA0KIA0KIAkJaWYgKCFj cHVfcG9zc2libGUoaSkpIA0KIAkJCWNvbnRpbnVlOw0KLQkJbGJfc3RhdHMg PSAmcGVyX2NwdShsb29wYmFja19zdGF0cywgZ2V0X2NwdSgpKTsNCisJCWxi X3N0YXRzID0gJnBlcl9jcHUobG9vcGJhY2tfc3RhdHMsIGkpOw0KIAkJc3Rh dHMtPnJ4X2J5dGVzICAgKz0gbGJfc3RhdHMtPnJ4X2J5dGVzOw0KIAkJc3Rh dHMtPnR4X2J5dGVzICAgKz0gbGJfc3RhdHMtPnR4X2J5dGVzOw0KIAkJc3Rh dHMtPnJ4X3BhY2tldHMgKz0gbGJfc3RhdHMtPnJ4X3BhY2tldHM7DQogCQlz dGF0cy0+dHhfcGFja2V0cyArPSBsYl9zdGF0cy0+dHhfcGFja2V0czsNCi0J CXB1dF9jcHUoKTsNCiAJfQ0KIAkJCQkNCiAJcmV0dXJuIHN0YXRzOw0K ---1072017398-688446164-1087937167=:1357620-- From shemminger@osdl.org Tue Jun 22 13:51:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 13:51:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MKpagi032206 for ; Tue, 22 Jun 2004 13:51:38 -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 i5MKpMr24679; Tue, 22 Jun 2004 13:51:22 -0700 Date: Tue, 22 Jun 2004 13:51:22 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] get rid of warnings from 8139too driver Message-Id: <20040622135122.05be2be1@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: 6251 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 Get rid of sparse warnings from 8139too driver. * move start_thread which was inline into the open routine (only place called). * handle #if constructs Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/8139too.c b/drivers/net/8139too.c --- a/drivers/net/8139too.c 2004-06-22 13:45:03 -07:00 +++ b/drivers/net/8139too.c 2004-06-22 13:45:03 -07:00 @@ -613,7 +613,7 @@ static int mdio_read (struct net_device *dev, int phy_id, int location); static void mdio_write (struct net_device *dev, int phy_id, int location, int val); -static inline void rtl8139_start_thread(struct net_device *dev); +static int rtl8139_thread (void *data); static void rtl8139_tx_timeout (struct net_device *dev); static void rtl8139_init_ring (struct net_device *dev); static int rtl8139_start_xmit (struct sk_buff *skb, @@ -1359,7 +1359,19 @@ dev->irq, RTL_R8 (MediaStatus), tp->mii.full_duplex ? "full" : "half"); - rtl8139_start_thread(dev); + + tp->thr_pid = -1; + tp->twistie = 0; + tp->time_to_die = 0; + if (tp->chipset == CH_8139_K) + tp->twistie = 1; + else if (!(tp->drv_flags & HAS_LNK_CHNG)) { + tp->thr_pid = kernel_thread(rtl8139_thread, dev, CLONE_FS|CLONE_FILES); + if (tp->thr_pid < 0) { + printk (KERN_WARNING "%s: unable to start kernel thread\n", + dev->name); + } + } return 0; } @@ -1643,25 +1655,6 @@ complete_and_exit (&tp->thr_exited, 0); } -static inline void rtl8139_start_thread(struct net_device *dev) -{ - struct rtl8139_private *tp = dev->priv; - - tp->thr_pid = -1; - tp->twistie = 0; - tp->time_to_die = 0; - if (tp->chipset == CH_8139_K) - tp->twistie = 1; - else if (tp->drv_flags & HAS_LNK_CHNG) - return; - - tp->thr_pid = kernel_thread(rtl8139_thread, dev, CLONE_FS|CLONE_FILES); - if (tp->thr_pid < 0) { - printk (KERN_WARNING "%s: unable to start kernel thread\n", - dev->name); - } -} - static inline void rtl8139_tx_clear (struct rtl8139_private *tp) { tp->cur_tx = 0; @@ -1960,7 +1953,7 @@ printk(KERN_DEBUG "%s: rtl8139_rx() status %4.4x, size %4.4x," " cur %4.4x.\n", dev->name, rx_status, rx_size, cur_rx); -#if RTL8139_DEBUG > 2 +#if defined(RTL8139_DEBUG) && RTL8139_DEBUG > 2 { int i; DPRINTK ("%s: Frame contents ", dev->name); @@ -2039,7 +2032,7 @@ done: -#if RTL8139_DEBUG > 1 +#if defined(RTL8139_DEBUG) && RTL8139_DEBUG > 1 DPRINTK ("%s: Done rtl8139_rx(), current %4.4x BufAddr %4.4x," " free to %4.4x, Cmd %2.2x.\n", dev->name, cur_rx, RTL_R16 (RxBufAddr), From shemminger@osdl.org Tue Jun 22 13:53:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 13:53:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MKr4gi032543 for ; Tue, 22 Jun 2004 13:53:04 -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 i5MKqrr24853; Tue, 22 Jun 2004 13:52:53 -0700 Date: Tue, 22 Jun 2004 13:52:53 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] get rid of warnings about #if DEBUG Message-Id: <20040622135253.43a9acde@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: 6253 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 Several drivers use '#if DEBUG' which is a warning under the sparse checker. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-06-22 13:47:25 -07:00 +++ b/drivers/net/acenic.c 2004-06-22 13:47:25 -07:00 @@ -1634,7 +1634,7 @@ cur_size = atomic_read(&ap->cur_rx_bufs); if ((cur_size < RX_LOW_STD_THRES) && !test_and_set_bit(0, &ap->std_refill_busy)) { -#if DEBUG +#ifdef DEBUG printk("refilling buffers (current %i)\n", cur_size); #endif ace_load_std_rx_ring(ap, RX_RING_SIZE - cur_size); @@ -1644,7 +1644,7 @@ cur_size = atomic_read(&ap->cur_mini_bufs); if ((cur_size < RX_LOW_MINI_THRES) && !test_and_set_bit(0, &ap->mini_refill_busy)) { -#if DEBUG +#ifdef DEBUG printk("refilling mini buffers (current %i)\n", cur_size); #endif @@ -1655,7 +1655,7 @@ cur_size = atomic_read(&ap->cur_jumbo_bufs); if (ap->jumbo && (cur_size < RX_LOW_JUMBO_THRES) && !test_and_set_bit(0, &ap->jumbo_refill_busy)) { -#if DEBUG +#ifdef DEBUG printk("refilling jumbo buffers (current %i)\n", cur_size); #endif ace_load_jumbo_rx_ring(ap, RX_JUMBO_SIZE - cur_size); @@ -2255,7 +2255,7 @@ if (cur_size < RX_LOW_STD_THRES) { if ((cur_size < RX_PANIC_STD_THRES) && !test_and_set_bit(0, &ap->std_refill_busy)) { -#if DEBUG +#ifdef DEBUG printk("low on std buffers %i\n", cur_size); #endif ace_load_std_rx_ring(ap, @@ -2270,7 +2270,7 @@ if ((cur_size < RX_PANIC_MINI_THRES) && !test_and_set_bit(0, &ap->mini_refill_busy)) { -#if DEBUG +#ifdef DEBUG printk("low on mini buffers %i\n", cur_size); #endif @@ -2286,7 +2286,7 @@ if ((cur_size < RX_PANIC_JUMBO_THRES) && !test_and_set_bit(0, &ap->jumbo_refill_busy)){ -#if DEBUG +#ifdef DEBUG printk("low on jumbo buffers %i\n", cur_size); #endif diff -Nru a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h --- a/drivers/net/ixgb/ixgb.h 2004-06-22 13:47:25 -07:00 +++ b/drivers/net/ixgb/ixgb.h 2004-06-22 13:47:25 -07:00 @@ -77,7 +77,7 @@ #include "ixgb_ee.h" #include "ixgb_ids.h" -#if _DEBUG_DRIVER_ +#ifdef _DEBUG_DRIVER_ #define IXGB_DBG(args...) printk(KERN_DEBUG "ixgb: " args) #else #define IXGB_DBG(args...) diff -Nru a/drivers/net/wan/sbni.h b/drivers/net/wan/sbni.h --- a/drivers/net/wan/sbni.h 2004-06-22 13:47:25 -07:00 +++ b/drivers/net/wan/sbni.h 2004-06-22 13:47:25 -07:00 @@ -6,7 +6,7 @@ #ifndef SBNI_H #define SBNI_H -#if SBNI_DEBUG +#ifdef SBNI_DEBUG #define DP( A ) A #else #define DP( A ) diff -Nru a/drivers/net/yellowfin.c b/drivers/net/yellowfin.c --- a/drivers/net/yellowfin.c 2004-06-22 13:47:25 -07:00 +++ b/drivers/net/yellowfin.c 2004-06-22 13:47:25 -07:00 @@ -65,7 +65,7 @@ static int bogus_rx; static int dma_ctrl = 0x004A0263; /* Constrained by errata */ static int fifo_cfg = 0x0020; /* Bypass external Tx FIFO. */ -#elif YF_NEW /* A future perfect board :->. */ +#elif defined(YF_NEW) /* A future perfect board :->. */ static int dma_ctrl = 0x00CAC277; /* Override when loading module! */ static int fifo_cfg = 0x0028; #else From davem@redhat.com Tue Jun 22 14:02:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:02:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ML1xgi001530 for ; Tue, 22 Jun 2004 14:02: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 i5ML1ue1003822; Tue, 22 Jun 2004 17:01:56 -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 i5ML1u011103; Tue, 22 Jun 2004 17:01:56 -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 i5ML1ZwC004658; Tue, 22 Jun 2004 17:01:35 -0400 Date: Tue, 22 Jun 2004 14:01:40 -0700 From: "David S. Miller" To: Arthur Kepner Cc: akpm@osdl.org, netdev@oss.sgi.com, chrisw@osdl.org, gillb4@telusplanet.net Subject: Re: [PATCH] preempt count regression w/ lockless loopback patch Message-Id: <20040622140140.66b26cd1.davem@redhat.com> In-Reply-To: References: <200406210510.i5L5A340018849@hera.kernel.org> <20040621035702.6114bdbe.akpm@osdl.org> <20040622123931.50d5ac05.davem@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: 6254 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 Tue, 22 Jun 2004 13:46:07 -0700 Arthur Kepner wrote: > On Tue, 22 Jun 2004, David S. Miller wrote: > > > .... > > Can you instead give a patch relative to Andrew's? His is > > applied already and in fact pushed into Linus's tree. > > > > Yes. It is in the attachment. Thanks a lot Arthur, patch applied. From shemminger@osdl.org Tue Jun 22 14:21:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:21:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLL0gi002527 for ; Tue, 22 Jun 2004 14:21:00 -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 i5MLKrr02958; Tue, 22 Jun 2004 14:20:53 -0700 Date: Tue, 22 Jun 2004 14:20:52 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (1/3) skfp - cleanup is_XXX functions Message-Id: <20040622142052.7b9af6bc@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: 6255 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 This started out from sparse warnings about calling with fddi_broadcast that is declared const. This fixes that and gets rid of some of the namespace pollution of this driver by moving the predicate function is_individual, is_broadcast, ... as inline's in the one file that uses them. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/skfp/h/cmtdef.h b/drivers/net/skfp/h/cmtdef.h --- a/drivers/net/skfp/h/cmtdef.h 2004-06-22 13:56:20 -07:00 +++ b/drivers/net/skfp/h/cmtdef.h 2004-06-22 13:56:20 -07:00 @@ -571,10 +571,6 @@ int port_to_mib(struct s_smc *smc, int p); int cem_build_path(struct s_smc *smc, char *to, int path_index); int sm_mac_get_tx_state(struct s_smc *smc); -int is_individual(struct fddi_addr *addr); -int is_my_addr(struct s_smc *smc, struct fddi_addr *addr); -int is_broadcast(struct fddi_addr *addr); -int is_equal(struct fddi_addr *addr1, struct fddi_addr *addr2); char *get_pcmstate(struct s_smc *smc, int np); int smt_action(struct s_smc *smc, int class, int code, int index); u_short smt_online(struct s_smc *smc, int on); diff -Nru a/drivers/net/skfp/smt.c b/drivers/net/skfp/smt.c --- a/drivers/net/skfp/smt.c 2004-06-22 13:56:20 -07:00 +++ b/drivers/net/skfp/smt.c 2004-06-22 13:56:20 -07:00 @@ -76,8 +76,8 @@ static int phy_con_resource_index(struct s_smc *smc, int phy); static void smt_send_rdf(struct s_smc *smc, SMbuf *rej, int fc, int reason, int local); -static void smt_send_nif(struct s_smc *smc, struct fddi_addr *dest, int fc, - u_long tid, int type, int local); +static void smt_send_nif(struct s_smc *smc, const struct fddi_addr *dest, + int fc, u_long tid, int type, int local); static void smt_send_ecf(struct s_smc *smc, struct fddi_addr *dest, int fc, u_long tid, int type, int len); static void smt_echo_test(struct s_smc *smc, int dna); @@ -123,6 +123,45 @@ #define hwm_conv_can(smc,data,len) #endif + +static inline int is_my_addr(const struct s_smc *smc, + const struct fddi_addr *addr) +{ + return(*(short *)(&addr->a[0]) == + *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[0]) + && *(short *)(&addr->a[2]) == + *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[2]) + && *(short *)(&addr->a[4]) == + *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[4])) ; +} + +static inline int is_zero(const struct fddi_addr *addr) +{ + return(*(short *)(&addr->a[0]) == 0 && + *(short *)(&addr->a[2]) == 0 && + *(short *)(&addr->a[4]) == 0 ) ; +} + +static inline int is_broadcast(const struct fddi_addr *addr) +{ + return(*(u_short *)(&addr->a[0]) == 0xffff && + *(u_short *)(&addr->a[2]) == 0xffff && + *(u_short *)(&addr->a[4]) == 0xffff ) ; +} + +static inline int is_individual(const struct fddi_addr *addr) +{ + return(!(addr->a[0] & GROUP_ADDR)) ; +} + +static inline int is_equal(const struct fddi_addr *addr1, + const struct fddi_addr *addr2) +{ + return(*(u_short *)(&addr1->a[0]) == *(u_short *)(&addr2->a[0]) && + *(u_short *)(&addr1->a[2]) == *(u_short *)(&addr2->a[2]) && + *(u_short *)(&addr1->a[4]) == *(u_short *)(&addr2->a[4]) ) ; +} + /* * list of mandatory paras in frames */ @@ -382,7 +421,7 @@ */ if (!smc->sm.pend[SMT_TID_NIF]) smc->sm.pend[SMT_TID_NIF] = smt_get_tid(smc) ; - smt_send_nif(smc,&fddi_broadcast,FC_SMT_NSA, + smt_send_nif(smc,&fddi_broadcast, FC_SMT_NSA, smc->sm.pend[SMT_TID_NIF], SMT_REQUEST,0) ; smc->sm.smt_last_notify = time ; } @@ -926,8 +965,8 @@ /* * generate and send NIF */ -static void smt_send_nif(struct s_smc *smc, struct fddi_addr *dest, int fc, - u_long tid, int type, int local) +static void smt_send_nif(struct s_smc *smc, const struct fddi_addr *dest, + int fc, u_long tid, int type, int local) /* struct fddi_addr *dest; dest address */ /* int fc; frame control */ /* u_long tid; transaction id */ @@ -1687,43 +1726,6 @@ } return(0) ; } - -int is_my_addr(struct s_smc *smc, struct fddi_addr *addr) -{ - return(*(short *)(&addr->a[0]) == - *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[0]) - && *(short *)(&addr->a[2]) == - *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[2]) - && *(short *)(&addr->a[4]) == - *(short *)(&smc->mib.m[MAC0].fddiMACSMTAddress.a[4])) ; -} - -int is_zero(struct fddi_addr *addr) -{ - return(*(short *)(&addr->a[0]) == 0 && - *(short *)(&addr->a[2]) == 0 && - *(short *)(&addr->a[4]) == 0 ) ; -} - -int is_broadcast(struct fddi_addr *addr) -{ - return(*(u_short *)(&addr->a[0]) == 0xffff && - *(u_short *)(&addr->a[2]) == 0xffff && - *(u_short *)(&addr->a[4]) == 0xffff ) ; -} - -int is_individual(struct fddi_addr *addr) -{ - return(!(addr->a[0] & GROUP_ADDR)) ; -} - -int is_equal(struct fddi_addr *addr1, struct fddi_addr *addr2) -{ - return(*(u_short *)(&addr1->a[0]) == *(u_short *)(&addr2->a[0]) && - *(u_short *)(&addr1->a[2]) == *(u_short *)(&addr2->a[2]) && - *(u_short *)(&addr1->a[4]) == *(u_short *)(&addr2->a[4]) ) ; -} - #if 0 /* From shemminger@osdl.org Tue Jun 22 14:22:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:22:15 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLMEgi002659 for ; Tue, 22 Jun 2004 14:22:14 -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 i5MLLmr03126; Tue, 22 Jun 2004 14:21:48 -0700 Date: Tue, 22 Jun 2004 14:21:48 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (2/3) skfp -- sparse __user annotation Message-Id: <20040622142148.287d402d@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: 6256 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 Add __user annotation to the device specific ioctl. diff -Nru a/drivers/net/skfp/h/targetos.h b/drivers/net/skfp/h/targetos.h --- a/drivers/net/skfp/h/targetos.h 2004-06-22 13:57:04 -07:00 +++ b/drivers/net/skfp/h/targetos.h 2004-06-22 13:57:04 -07:00 @@ -110,7 +110,7 @@ struct s_skfp_ioctl { unsigned short cmd; /* Command to run */ unsigned short len; /* Length of the data buffer */ - unsigned char *data; /* Pointer to the data buffer */ + unsigned char __user *data; /* Pointer to the data buffer */ }; /* From shemminger@osdl.org Tue Jun 22 14:23:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:24:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLNugi003165 for ; Tue, 22 Jun 2004 14:23: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 i5MLNpr03493 for ; Tue, 22 Jun 2004 14:23:51 -0700 Date: Tue, 22 Jun 2004 14:23:51 -0700 From: Stephen Hemminger To: netdev@oss.sgi.com Subject: [PATCH] [sparse] net drivers assignment in conditional context Message-Id: <20040622142351.1857bb9b@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: 6257 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 Fix several warnings from sparse about assignment used in conditional context in net drivers Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/3c505.c b/drivers/net/3c505.c --- a/drivers/net/3c505.c 2004-06-22 13:43:47 -07:00 +++ b/drivers/net/3c505.c 2004-06-22 13:43:47 -07:00 @@ -1373,7 +1373,7 @@ if (elp_sense(dev) == 0) return dev->base_addr; } else - while ((dev->base_addr = addr_list[idx++])) { + while ((dev->base_addr = addr_list[idx++]) != 0) { if (elp_sense(dev) == 0) return dev->base_addr; } diff -Nru a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c --- a/drivers/net/cs89x0.c 2004-06-22 13:43:46 -07:00 +++ b/drivers/net/cs89x0.c 2004-06-22 13:43:46 -07:00 @@ -1430,7 +1430,7 @@ course, if you're on a slow machine, and packets are arriving faster than you can read them off, you're screwed. Hasta la vista, baby! */ - while ((status = readword(dev, ISQ_PORT))) { + while ((status = readword(dev, ISQ_PORT)) != 0) { if (net_debug > 4)printk("%s: event=%04x\n", dev->name, status); handled = 1; switch(status & ISQ_EVENT_MASK) { diff -Nru a/drivers/net/eth16i.c b/drivers/net/eth16i.c --- a/drivers/net/eth16i.c 2004-06-22 13:43:46 -07:00 +++ b/drivers/net/eth16i.c 2004-06-22 13:43:46 -07:00 @@ -446,12 +446,12 @@ return -ENXIO; /* Seek card from the ISA io address space */ - for(i = 0; (ioaddr = eth16i_portlist[i]) ; i++) + for(i = 0; (ioaddr = eth16i_portlist[i]) != 0; i++) if(eth16i_probe1(dev, ioaddr) == 0) return 0; /* Seek card from the EISA io address space */ - for(i = 0; (ioaddr = eth32i_portlist[i]) ; i++) + for(i = 0; (ioaddr = eth32i_portlist[i]) != 0; i++) if(eth16i_probe1(dev, ioaddr) == 0) return 0; diff -Nru a/drivers/net/ne.c b/drivers/net/ne.c --- a/drivers/net/ne.c 2004-06-22 13:43:46 -07:00 +++ b/drivers/net/ne.c 2004-06-22 13:43:46 -07:00 @@ -242,7 +242,7 @@ while ((idev = pnp_find_dev(NULL, isapnp_clone_list[i].vendor, isapnp_clone_list[i].function, - idev))) { + idev)) != NULL) { /* Avoid already found cards from previous calls */ if (pnp_device_attach(idev) < 0) continue; diff -Nru a/drivers/net/ni52.c b/drivers/net/ni52.c --- a/drivers/net/ni52.c 2004-06-22 13:43:46 -07:00 +++ b/drivers/net/ni52.c 2004-06-22 13:43:46 -07:00 @@ -855,7 +855,7 @@ WAIT_4_SCB_CMD(); /* wait for last command */ - while((stat=p->scb->cus & STAT_MASK)) + while((stat=p->scb->cus & STAT_MASK) != 0) { p->scb->cmd_cuc = stat; ni_attn586(); diff -Nru a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c --- a/drivers/net/pcnet32.c 2004-06-22 13:43:46 -07:00 +++ b/drivers/net/pcnet32.c 2004-06-22 13:43:46 -07:00 @@ -959,7 +959,7 @@ unsigned int *port, ioaddr; /* search for PCnet32 VLB cards at known addresses */ - for (port = pcnet32_portlist; (ioaddr = *port); port++) { + for (port = pcnet32_portlist; (ioaddr = *port) != 0; port++) { if (request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_vlbus")) { /* check if there is really a pcnet chip on that ioaddr */ if ((inb(ioaddr + 14) == 0x57) && (inb(ioaddr + 15) == 0x57)) { diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c 2004-06-22 13:43:47 -07:00 +++ b/drivers/net/via-rhine.c 2004-06-22 13:43:47 -07:00 @@ -1389,7 +1389,7 @@ ioaddr = dev->base_addr; - while ((intr_status = get_intr_status(dev))) { + while ((intr_status = get_intr_status(dev)) != 0) { handled = 1; /* Acknowledge all of the current interrupt sources ASAP. */ diff -Nru a/drivers/net/wan/syncppp.c b/drivers/net/wan/syncppp.c --- a/drivers/net/wan/syncppp.c 2004-06-22 13:43:46 -07:00 +++ b/drivers/net/wan/syncppp.c 2004-06-22 13:43:46 -07:00 @@ -1142,7 +1142,7 @@ spin_lock_irqsave(&spppq_lock, flags); /* Remove the entry from the keepalive list. */ - for (q = &spppq; (p = *q); q = &p->pp_next) + for (q = &spppq; (p = *q) != NULL; q = &p->pp_next) if (p == sp) { *q = p->pp_next; break; From SRS0+e0f03d060ce0ffee2940+303+infradead.org+hch@pentafluge-222648.srs.infradead.org Tue Jun 22 14:26:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:26:51 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLQmgi003536 for ; Tue, 22 Jun 2004 14:26:49 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1Bcsn2-0002ku-0P; Tue, 22 Jun 2004 22:26:48 +0100 Date: Tue, 22 Jun 2004 22:26:47 +0100 From: Christoph Hellwig To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] net drivers assignment in conditional context Message-ID: <20040622212647.GA10589@infradead.org> References: <20040622142351.1857bb9b@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040622142351.1857bb9b@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Tue, Jun 22, 2004 at 02:23:51PM -0700, Stephen Hemminger wrote: > Fix several warnings from sparse about assignment used in conditional > context in net drivers The patch is junk. Fix sparse instead. From shemminger@osdl.org Tue Jun 22 14:27:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:27:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLRigi003828 for ; Tue, 22 Jun 2004 14:27:44 -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 i5MLRMr04053; Tue, 22 Jun 2004 14:27:22 -0700 Date: Tue, 22 Jun 2004 14:27:22 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] dgrs -- cleanup warnings Message-Id: <20040622142722.343300b3@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: 6259 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 DGRS driver sparse fixes. Add annotation to ioctl structure and get rid of '#if XXX' Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/dgrs.h b/drivers/net/dgrs.h --- a/drivers/net/dgrs.h 2004-06-22 14:25:43 -07:00 +++ b/drivers/net/dgrs.h 2004-06-22 14:25:43 -07:00 @@ -26,7 +26,7 @@ typedef struct dgrs_ioctl { unsigned short cmd; /* Command to run */ unsigned short len; /* Length of the data buffer */ - unsigned char *data; /* Pointer to the data buffer */ + unsigned char __user *data;/* Pointer to the data buffer */ unsigned short port; /* port number for command, if needed */ unsigned short filter; /* filter number for command, if needed */ } DGRS_IOCTL; diff -Nru a/drivers/net/dgrs_asstruct.h b/drivers/net/dgrs_asstruct.h --- a/drivers/net/dgrs_asstruct.h 2004-06-22 14:25:43 -07:00 +++ b/drivers/net/dgrs_asstruct.h 2004-06-22 14:25:43 -07:00 @@ -4,7 +4,7 @@ * $Id: asstruct.h,v 1.1.1.1 1994/10/23 05:08:32 rick Exp $ */ -#if ASSEMBLER +#ifdef ASSEMBLER # define MO(t,a) (a) # define VMO(t,a) (a) From shemminger@osdl.org Tue Jun 22 14:34:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:34:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLYTgi004291 for ; Tue, 22 Jun 2004 14:34:29 -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 i5MLYFr05917; Tue, 22 Jun 2004 14:34:15 -0700 Date: Tue, 22 Jun 2004 14:34:15 -0700 From: Stephen Hemminger To: Christoph Hellwig Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] net drivers assignment in conditional context Message-Id: <20040622143415.52ad9fcc@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622212647.GA10589@infradead.org> References: <20040622142351.1857bb9b@dell_ss3.pdx.osdl.net> <20040622212647.GA10589@infradead.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: 6260 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 Tue, 22 Jun 2004 22:26:47 +0100 Christoph Hellwig wrote: > On Tue, Jun 22, 2004 at 02:23:51PM -0700, Stephen Hemminger wrote: > > Fix several warnings from sparse about assignment used in conditional > > context in net drivers > > The patch is junk. Fix sparse instead. Not according to Linus. Convince him first. From jgarzik@pobox.com Tue Jun 22 14:49:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 14:49: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.12.10/8.12.9) with SMTP id i5MLnGgi004982 for ; Tue, 22 Jun 2004 14:49:16 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bct8l-0005jF-6x; Tue, 22 Jun 2004 22:49:15 +0100 Message-ID: <40D8A94E.3040509@pobox.com> Date: Tue, 22 Jun 2004 17:49:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] net drivers assignment in conditional context References: <20040622142351.1857bb9b@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622142351.1857bb9b@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6261 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 Stephen Hemminger wrote: > Fix several warnings from sparse about assignment used in conditional > context in net drivers For the purposes of netdev... I objected in private to this patch, as just a bunch of noise. Jeff From shemminger@osdl.org Tue Jun 22 15:55:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 15:55:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MMt6gi006748 for ; Tue, 22 Jun 2004 15:55:06 -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 i5MMsrr25210; Tue, 22 Jun 2004 15:54:53 -0700 Date: Tue, 22 Jun 2004 15:54:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] rtentry->rt_dev is __user Message-Id: <20040622155453.564ede17@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: 6262 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 The device entry in the route ioctl's needs annotation. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/route.h b/include/linux/route.h --- a/include/linux/route.h 2004-06-22 15:49:41 -07:00 +++ b/include/linux/route.h 2004-06-22 15:49:41 -07:00 @@ -24,7 +24,7 @@ #define _LINUX_ROUTE_H #include - +#include /* This structure gets passed by the SIOCADDRT and SIOCDELRT calls. */ struct rtentry @@ -38,7 +38,7 @@ unsigned long rt_pad3; void *rt_pad4; short rt_metric; /* +1 for binary compatibility! */ - char *rt_dev; /* forcing the device at add */ + char __user *rt_dev; /* forcing the device at add */ unsigned long rt_mtu; /* per route MTU/Window */ #ifndef __KERNEL__ #define rt_mss rt_mtu /* Compatibility :-( */ From shemminger@osdl.org Tue Jun 22 16:00:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 16:00:36 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MN0Ygi007158 for ; Tue, 22 Jun 2004 16:00:34 -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 i5MN0Mr26080; Tue, 22 Jun 2004 16:00:22 -0700 Date: Tue, 22 Jun 2004 16:00:22 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] ip_rt_ioctl argument is user pointer Message-Id: <20040622160022.75db69bb@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: 6263 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 The function ip_rt_ioctl expects a pointer to a user route structure, so define it that way and cast as appropriate. diff -Nru a/include/net/route.h b/include/net/route.h --- a/include/net/route.h 2004-06-22 15:57:28 -07:00 +++ b/include/net/route.h 2004-06-22 15:57:28 -07:00 @@ -129,7 +129,7 @@ extern unsigned inet_addr_type(u32 addr); extern void ip_rt_multicast_event(struct in_device *); -extern int ip_rt_ioctl(unsigned int cmd, void *arg); +extern int ip_rt_ioctl(unsigned int cmd, void __user *arg); extern void ip_rt_get_source(u8 *src, struct rtable *rt); extern int ip_rt_dump(struct sk_buff *skb, struct netlink_callback *cb); diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c 2004-06-22 15:57:28 -07:00 +++ b/net/ipv4/af_inet.c 2004-06-22 15:57:28 -07:00 @@ -848,7 +848,7 @@ case SIOCADDRT: case SIOCDELRT: case SIOCRTMSG: - err = ip_rt_ioctl(cmd, (void *)arg); + err = ip_rt_ioctl(cmd, (void __user *)arg); break; case SIOCDARP: case SIOCGARP: diff -Nru a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c --- a/net/ipv4/fib_frontend.c 2004-06-22 15:57:28 -07:00 +++ b/net/ipv4/fib_frontend.c 2004-06-22 15:57:28 -07:00 @@ -235,7 +235,7 @@ * Handle IP routing ioctl calls. These are used to manipulate the routing tables */ -int ip_rt_ioctl(unsigned int cmd, void *arg) +int ip_rt_ioctl(unsigned int cmd, void __user *arg) { int err; struct kern_rta rta; diff -Nru a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c --- a/net/ipv4/ipconfig.c 2004-06-22 15:57:28 -07:00 +++ b/net/ipv4/ipconfig.c 2004-06-22 15:57:28 -07:00 @@ -272,7 +272,7 @@ mm_segment_t oldfs = get_fs(); set_fs(get_ds()); - res = devinet_ioctl(cmd, arg); + res = devinet_ioctl(cmd, (struct ifreq __user *) arg); set_fs(oldfs); return res; } @@ -283,7 +283,7 @@ mm_segment_t oldfs = get_fs(); set_fs(get_ds()); - res = ip_rt_ioctl(cmd, arg); + res = ip_rt_ioctl(cmd, (void __user *) arg); set_fs(oldfs); return res; } From shemminger@osdl.org Tue Jun 22 16:11:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 16:11:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MNBdgi007797 for ; Tue, 22 Jun 2004 16:11: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 i5MNBUr28786; Tue, 22 Jun 2004 16:11:30 -0700 Date: Tue, 22 Jun 2004 16:11:30 -0700 From: Stephen Hemminger To: Mirko Lindner , Ralph Roesler Cc: netdev@oss.sgi.com Subject: [RFT] convert syskonnect gigabit ether driver to PCI module interface Message-Id: <20040622161130.0adaac78@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: multipart/mixed; boundary="Multipart=_Tue__22_Jun_2004_16_11_30_-0700_8uIkj/kgIxNhFzbe" X-archive-position: 6264 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 This is a multi-part message in MIME format. --Multipart=_Tue__22_Jun_2004_16_11_30_-0700_8uIkj/kgIxNhFzbe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This patch converts the SysKonnect Gigabit Ethernet (Yukon) driver from the old pci_find_class infrastructure, to the current 2.4/2.6 pci_module probing model. The device identification is no longer done in the macro, but in a pci_device_id table like other drivers. I don't have any hardware to test it on, but it builds on 2.6; could someone please validate that it correctly finds and initializes all the ports on the card. --Multipart=_Tue__22_Jun_2004_16_11_30_-0700_8uIkj/kgIxNhFzbe Content-Type: text/plain; name="skge-pci-ids.patch" Content-Disposition: attachment; filename="skge-pci-ids.patch" Content-Transfer-Encoding: quoted-printable diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h --- a/include/linux/pci_ids.h 2004-06-22 10:08:12 -07:00 +++ b/include/linux/pci_ids.h 2004-06-22 10:08:12 -07:00 @@ -967,12 +967,14 @@ =20 #define PCI_VENDOR_ID_3COM 0x10b7 #define PCI_DEVICE_ID_3COM_3C985 0x0001 +#define PCI_DEVICE_ID_3COM_3C940 0x1700 #define PCI_DEVICE_ID_3COM_3C339 0x3390 #define PCI_DEVICE_ID_3COM_3C359 0x3590 #define PCI_DEVICE_ID_3COM_3C590 0x5900 #define PCI_DEVICE_ID_3COM_3C595TX 0x5950 #define PCI_DEVICE_ID_3COM_3C595T4 0x5951 #define PCI_DEVICE_ID_3COM_3C595MII 0x5952 +#define PCI_DEVICE_ID_3COM_3C940B 0x80eb #define PCI_DEVICE_ID_3COM_3C900TPO 0x9000 #define PCI_DEVICE_ID_3COM_3C900COMBO 0x9001 #define PCI_DEVICE_ID_3COM_3C905TX 0x9050 @@ -1420,6 +1422,9 @@ #define PCI_DEVICE_ID_RICOH_RL5C476 0x0476 #define PCI_DEVICE_ID_RICOH_RL5C478 0x0478 =20 +#define PCI_VENDOR_ID_DLINK 0x1186 +#define PCI_DEVICE_ID_DLINK_DGE510T 0x4c00 + #define PCI_VENDOR_ID_ARTOP 0x1191 #define PCI_DEVICE_ID_ARTOP_ATP8400 0x0004 #define PCI_DEVICE_ID_ARTOP_ATP850UF 0x0005 @@ -1735,6 +1740,9 @@ #define PCI_VENDOR_ID_KAWASAKI 0x136b #define PCI_DEVICE_ID_MCHIP_KL5A72002 0xff01 =20 +#define PCI_VENDOR_ID_CNET 0x1371 +#define PCI_DEVICE_ID_CNET_GIGACARD 0x434e + #define PCI_VENDOR_ID_LMC 0x1376 #define PCI_DEVICE_ID_LMC_HSSI 0x0003 #define PCI_DEVICE_ID_LMC_DS3 0x0004 @@ -1918,6 +1926,10 @@ #define PCI_DEVICE_ID_FARSITE_T4U 0x0640 #define PCI_DEVICE_ID_FARSITE_TE1 0x1610 #define PCI_DEVICE_ID_FARSITE_TE1C 0x1612 + +#define PCI_VENDOR_ID_LINKSYS 0x1737 +#define PCI_DEVICE_ID_LINKSYS_EG1032 0x1032 +#define PCI_DEVICE_ID_LINKSYS_EG1064 0x1064 =20 #define PCI_VENDOR_ID_ALTIMA 0x173b #define PCI_DEVICE_ID_ALTIMA_AC1000 0x03e8 --Multipart=_Tue__22_Jun_2004_16_11_30_-0700_8uIkj/kgIxNhFzbe Content-Type: application/octet-stream; name="skge-pci-init.patch" Content-Disposition: attachment; filename="skge-pci-init.patch" Content-Transfer-Encoding: quoted-printable # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/22 15:57:48-07:00 shemminger@zqx3.pdx.osdl.net=20 # skge-2 #=20 # drivers/net/sk98lin/h/skdrv2nd.h # 2004/06/22 15:56:10-07:00 shemminger@zqx3.pdx.osdl.net +1 -55 # Import patch skge-2 #=20 # ChangeSet # 2004/06/22 15:53:11-07:00 shemminger@zqx3.pdx.osdl.net=20 # skge-pci #=20 # drivers/net/sk98lin/skge.c # 2004/06/22 11:12:17-07:00 shemminger@zqx3.pdx.osdl.net +270 -292 # Import patch skge-pci #=20 diff -Nru a/drivers/net/sk98lin/h/skdrv2nd.h b/drivers/net/sk98lin/h/skdrv2= nd.h --- a/drivers/net/sk98lin/h/skdrv2nd.h 2004-06-22 15:59:00 -07:00 +++ b/drivers/net/sk98lin/h/skdrv2nd.h 2004-06-22 15:59:00 -07:00 @@ -53,60 +53,6 @@ #include "h/skrlmt.h" #include "h/skgedrv.h" =20 -#define SK_PCI_ISCOMPLIANT(result, pdev) { \ - result =3D SK_FALSE; /* default */ \ - /* 3Com (0x10b7) */ \ - if (pdev->vendor =3D=3D 0x10b7) { \ - /* Gigabit Ethernet Adapter (0x1700) */ \ - if ((pdev->device =3D=3D 0x1700) || \ - (pdev->device =3D=3D 0x80eb)) { \ - result =3D SK_TRUE; \ - } \ - /* SysKonnect (0x1148) */ \ - } else if (pdev->vendor =3D=3D 0x1148) { \ - /* SK-98xx Gigabit Ethernet Server Adapter (0x4300) */ \ - /* SK-98xx V2.0 Gigabit Ethernet Adapter (0x4320) */ \ - if ((pdev->device =3D=3D 0x4300) || \ - (pdev->device =3D=3D 0x4320)) { \ - result =3D SK_TRUE; \ - } \ - /* D-Link (0x1186) */ \ - } else if (pdev->vendor =3D=3D 0x1186) { \ - /* Gigabit Ethernet Adapter (0x4c00) */ \ - if ((pdev->device =3D=3D 0x4c00)) { \ - result =3D SK_TRUE; \ - } \ - /* Marvell (0x11ab) */ \ - } else if (pdev->vendor =3D=3D 0x11ab) { \ - /* Gigabit Ethernet Adapter (0x4320) */ \ - /* Gigabit Ethernet Adapter (0x4360) */ \ - /* Gigabit Ethernet Adapter (0x4361) */ \ - /* Belkin (0x5005) */ \ - if ((pdev->device =3D=3D 0x4320) || \ - (pdev->device =3D=3D 0x4360) || \ - (pdev->device =3D=3D 0x4361) || \ - (pdev->device =3D=3D 0x5005)) { \ - result =3D SK_TRUE; \ - } \ - /* CNet (0x1371) */ \ - } else if (pdev->vendor =3D=3D 0x1371) { \ - /* GigaCard Network Adapter (0x434e) */ \ - if ((pdev->device =3D=3D 0x434e)) { \ - result =3D SK_TRUE; \ - } \ - /* Linksys (0x1737) */ \ - } else if (pdev->vendor =3D=3D 0x1737) { \ - /* Gigabit Network Adapter (0x1032) */ \ - /* Gigabit Network Adapter (0x1064) */ \ - if ((pdev->device =3D=3D 0x1032) || \ - (pdev->device =3D=3D 0x1064)) { \ - result =3D SK_TRUE; \ - } \ - } else { \ - result =3D SK_FALSE; \ - } \ -} - =20 extern SK_MBUF *SkDrvAllocRlmtMbuf(SK_AC*, SK_IOC, unsigned); extern void SkDrvFreeRlmtMbuf(SK_AC*, SK_IOC, SK_MBUF*); diff -Nru a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c --- a/drivers/net/sk98lin/skge.c 2004-06-22 15:59:00 -07:00 +++ b/drivers/net/sk98lin/skge.c 2004-06-22 15:59:00 -07:00 @@ -257,26 +257,40 @@ /* global variables ******************************************************= ***/ static const char *BootString =3D BOOT_STRING; struct SK_NET_DEVICE *SkGeRootDev =3D NULL; -static int probed __initdata =3D 0; static SK_BOOL DoPrintInterfaceChange =3D SK_TRUE; =20 /* local variables *******************************************************= ***/ static uintptr_t TxQueueAddr[SK_MAX_MACS][2] =3D {{0x680, 0x600},{0x780, 0= x700}}; static uintptr_t RxQueueAddr[SK_MAX_MACS] =3D {0x400, 0x480}; =20 - -#ifdef CONFIG_PROC_FS -static struct proc_dir_entry *pSkRootDir; -#endif - - +#define SK_PCI_DEVICE(vend, dev) \ + { PCI_DEVICE(vend, dev), \ + .class =3D PCI_CLASS_NETWORK_ETHERNET << 8, \ + .class_mask =3D 0xffff00, } + +static struct pci_device_id skge_pci_table[] =3D { + SK_PCI_DEVICE(PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3C940), + SK_PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_GE), + SK_PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_YU), + SK_PCI_DEVICE(PCI_VENDOR_ID_DLINK, PCI_DEVICE_ID_DLINK_DGE510T), + SK_PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4320), +/* Don't handle Yukon2 cards at the moment */ +/* 12-feb-2004 ---- mlindner@syskonnect.de */ +// SK_PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361), + SK_PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x5005), /* Belkin (0x5005) */=20 + SK_PCI_DEVICE(PCI_VENDOR_ID_CNET, PCI_DEVICE_ID_CNET_GIGACARD), + SK_PCI_DEVICE(PCI_VENDOR_ID_LINKSYS, PCI_DEVICE_ID_LINKSYS_EG1032), + SK_PCI_DEVICE(PCI_VENDOR_ID_LINKSYS, PCI_DEVICE_ID_LINKSYS_EG1064), + { 0 } +}; +MODULE_DEVICE_TABLE(pci, skge_pci_table); =20 /*************************************************************************= **** * - * skge_probe - find all SK-98xx adapters + * skge_init_one -- initialize one PCI board * * Description: - * This function scans the PCI bus for SK-98xx adapters. Resources for + * This function initializes a SK-98xx adapter. Resources for * each adapter are allocated and the adapter is brought into Init 1 * state. * @@ -284,13 +298,12 @@ * 0, if everything is ok * !=3D0, on error */ -static int __init skge_probe (void) +static int __devinit skge_init_one (struct pci_dev *pdev, + const struct pci_device_id *ent) { - int boards_found =3D 0; - int vendor_flag =3D SK_FALSE; + static int boards_found =3D 0; SK_AC *pAC; DEV_NET *pNet =3D NULL; - struct pci_dev *pdev =3D NULL; struct SK_NET_DEVICE *dev =3D NULL; SK_BOOL DeviceFound =3D SK_FALSE; SK_BOOL BootStringCount =3D SK_FALSE; @@ -299,257 +312,230 @@ struct proc_dir_entry *pProcFile; #endif =20 - if (probed) - return -ENODEV; - probed++; - - - while((pdev =3D pci_find_class(PCI_CLASS_NETWORK_ETHERNET << 8, pdev))) { - - if (pci_enable_device(pdev)) { - continue; - } - dev =3D NULL; - pNet =3D NULL; - - /* Don't handle Yukon2 cards at the moment */ - /* 12-feb-2004 ---- mlindner@syskonnect.de */ - if (pdev->vendor =3D=3D 0x11ab) { - if ( (pdev->device =3D=3D 0x4360) || (pdev->device =3D=3D 0x4361) ) - continue; - } - - SK_PCI_ISCOMPLIANT(vendor_flag, pdev); - if (!vendor_flag) - continue; - - /* Configure DMA attributes. */ - if (pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL) && - pci_set_dma_mask(pdev, (u64) 0xffffffff)) - continue; - - - if ((dev =3D alloc_etherdev(sizeof(DEV_NET))) =3D=3D NULL) { - printk(KERN_ERR "Unable to allocate etherdev " - "structure!\n"); - break; - } - - pNet =3D dev->priv; - pNet->pAC =3D kmalloc(sizeof(SK_AC), GFP_KERNEL); - if (pNet->pAC =3D=3D NULL){ - free_netdev(dev); - printk(KERN_ERR "Unable to allocate adapter " - "structure!\n"); - break; - } + retval =3D pci_enable_device(pdev); + if (retval) + goto err_out; + + /* Configure DMA attributes. */ + retval =3D pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL); + if (retval) + retval =3D pci_set_dma_mask(pdev, (u64) 0xffffffff); +=09 + if (retval) { + printk(KERN_ERR "Can't setup pci DMA\n"); + goto err_out; + } +=09 + if ((dev =3D alloc_etherdev(sizeof(DEV_NET) + sizeof(SK_AC))) =3D=3D NULL= ) { + printk(KERN_ERR "Unable to allocate etherdev " + "structure!\n"); + retval =3D -ENOMEM; + goto err_out; + } =20 - /* Print message */ - if (!BootStringCount) { - /* set display flag to TRUE so that */ - /* we only display this string ONCE */ - BootStringCount =3D SK_TRUE; - printk("%s\n", BootString); - } + pNet =3D dev->priv; + pNet->pAC =3D kmalloc(sizeof(SK_AC), GFP_KERNEL); + if (pNet->pAC =3D=3D NULL){ + printk(KERN_ERR "Unable to allocate adapter " + "structure!\n"); + goto free_dev_err; + } =20 - memset(pNet->pAC, 0, sizeof(SK_AC)); - pAC =3D pNet->pAC; - pAC->PciDev =3D pdev; - pAC->PciDevId =3D pdev->device; - pAC->dev[0] =3D dev; - pAC->dev[1] =3D dev; - sprintf(pAC->Name, "SysKonnect SK-98xx"); - pAC->CheckQueue =3D SK_FALSE; - - pNet->Mtu =3D 1500; - pNet->Up =3D 0; - dev->irq =3D pdev->irq; - retval =3D SkGeInitPCI(pAC); - if (retval) { - printk("SKGE: PCI setup failed: %i\n", retval); - free_netdev(dev); - continue; - } + /* Print message */ + if (!BootStringCount) { + /* set display flag to TRUE so that */ + /* we only display this string ONCE */ + BootStringCount =3D SK_TRUE; + printk("%s\n", BootString); + } +=09 + memset(pNet->pAC, 0, sizeof(SK_AC)); + pAC =3D pNet->pAC; + pAC->PciDev =3D pdev; + pAC->PciDevId =3D pdev->device; + pAC->dev[0] =3D dev; + pAC->dev[1] =3D dev; + sprintf(pAC->Name, "SysKonnect SK-98xx"); + pAC->CheckQueue =3D SK_FALSE; + + pNet->Mtu =3D 1500; + pNet->Up =3D 0; + dev->irq =3D pdev->irq; + retval =3D SkGeInitPCI(pAC); + if (retval) { + printk("SKGE: PCI setup failed: %i\n", retval); + goto free_dev_err; + } =20 - SET_MODULE_OWNER(dev); - dev->open =3D &SkGeOpen; - dev->stop =3D &SkGeClose; - dev->hard_start_xmit =3D &SkGeXmit; - dev->get_stats =3D &SkGeStats; - dev->last_stats =3D &SkGeStats; - dev->set_multicast_list =3D &SkGeSetRxMode; - dev->set_mac_address =3D &SkGeSetMacAddr; - dev->do_ioctl =3D &SkGeIoctl; - dev->change_mtu =3D &SkGeChangeMtu; - dev->flags &=3D ~IFF_RUNNING; - SET_NETDEV_DEV(dev, &pdev->dev); + SET_MODULE_OWNER(dev); + dev->open =3D &SkGeOpen; + dev->stop =3D &SkGeClose; + dev->hard_start_xmit =3D &SkGeXmit; + dev->get_stats =3D &SkGeStats; + dev->last_stats =3D &SkGeStats; + dev->set_multicast_list =3D &SkGeSetRxMode; + dev->set_mac_address =3D &SkGeSetMacAddr; + dev->do_ioctl =3D &SkGeIoctl; + dev->change_mtu =3D &SkGeChangeMtu; + dev->flags &=3D ~IFF_RUNNING; + SET_NETDEV_DEV(dev, &pdev->dev); + pci_set_drvdata(pdev, dev); =20 #ifdef SK_ZEROCOPY #ifdef USE_SK_TX_CHECKSUM =20 - if (pAC->ChipsetType) { - /* Use only if yukon hardware */ - /* SK and ZEROCOPY - fly baby... */ - dev->features |=3D NETIF_F_SG | NETIF_F_IP_CSUM; - } + if (pAC->ChipsetType) { + /* Use only if yukon hardware */ + /* SK and ZEROCOPY - fly baby... */ + dev->features |=3D NETIF_F_SG | NETIF_F_IP_CSUM; + } #endif #endif =20 - pAC->Index =3D boards_found; + pAC->Index =3D ++boards_found; =20 - if (SkGeBoardInit(dev, pAC)) { - free_netdev(dev); - continue; - } + if((retval =3D SkGeBoardInit(dev, pAC)) !=3D 0) + goto free_dev_err; =20 - /* Register net device */ - if (register_netdev(dev)) { - printk(KERN_ERR "SKGE: Could not register device.\n"); - FreeResources(dev); - free_netdev(dev); - continue; - } + /* Register net device */ + if ((retval =3D register_netdev(dev)) !=3D 0) { + printk(KERN_ERR "SKGE: Could not register device.\n"); + FreeResources(dev); + goto free_dev_err; + } =20 - /* Print adapter specific string from vpd */ - ProductStr(pAC); - printk("%s: %s\n", dev->name, pAC->DeviceStr); - - /* Print configuration settings */ - printk(" PrefPort:%c RlmtMode:%s\n", - 'A' + pAC->Rlmt.Net[0].Port[pAC->Rlmt.Net[0].PrefPort]->PortNumber, - (pAC->RlmtMode=3D=3D0) ? "Check Link State" : - ((pAC->RlmtMode=3D=3D1) ? "Check Link State" : - ((pAC->RlmtMode=3D=3D3) ? "Check Local Port" : - ((pAC->RlmtMode=3D=3D7) ? "Check Segmentation" : - ((pAC->RlmtMode=3D=3D17) ? "Dual Check Link State" :"Error"))))); + /* Print adapter specific string from vpd */ + ProductStr(pAC); + printk("%s: %s\n", dev->name, pAC->DeviceStr); + + /* Print configuration settings */ + printk(" PrefPort:%c RlmtMode:%s\n", + 'A' + pAC->Rlmt.Net[0].Port[pAC->Rlmt.Net[0].PrefPort]->PortNumber, + (pAC->RlmtMode=3D=3D0) ? "Check Link State" : + ((pAC->RlmtMode=3D=3D1) ? "Check Link State" : + ((pAC->RlmtMode=3D=3D3) ? "Check Local Port" : + ((pAC->RlmtMode=3D=3D7) ? "Check Segmentation" : + ((pAC->RlmtMode=3D=3D17) ? "Dual Check Link State" :"Error"))))); =20 - SkGeYellowLED(pAC, pAC->IoBase, 1); + SkGeYellowLED(pAC, pAC->IoBase, 1); =20 =20 - memcpy((caddr_t) &dev->dev_addr, - (caddr_t) &pAC->Addr.Net[0].CurrentMacAddress, 6); + memcpy((caddr_t) &dev->dev_addr, + (caddr_t) &pAC->Addr.Net[0].CurrentMacAddress, 6); =20 - /* First adapter... Create proc and print message */ + /* First adapter... Create proc and print message */ #ifdef CONFIG_PROC_FS - if (!DeviceFound) { - DeviceFound =3D SK_TRUE; - SK_MEMCPY(&SK_Root_Dir_entry, BootString, - sizeof(SK_Root_Dir_entry) - 1); - - /*Create proc (directory)*/ - if(!pSkRootDir) { - pSkRootDir =3D proc_mkdir(SK_Root_Dir_entry, proc_net); - if (!pSkRootDir) { - printk(KERN_WARNING "%s: Unable to create /proc/net/%s", - dev->name, SK_Root_Dir_entry); - } else { - pSkRootDir->owner =3D THIS_MODULE; - } + if (!DeviceFound) { + DeviceFound =3D SK_TRUE; + SK_MEMCPY(&SK_Root_Dir_entry, BootString, + sizeof(SK_Root_Dir_entry) - 1); + + /*Create proc (directory)*/ + if(!pSkRootDir) { + pSkRootDir =3D proc_mkdir(SK_Root_Dir_entry, proc_net); + if (!pSkRootDir) { + printk(KERN_WARNING "%s: Unable to create /proc/net/%s", + dev->name, SK_Root_Dir_entry); + } else { + pSkRootDir->owner =3D THIS_MODULE; } } + } =20 - /* Create proc file */ - if (pSkRootDir &&=20 - (pProcFile =3D create_proc_entry(dev->name, S_IRUGO, - pSkRootDir))) { - pProcFile->proc_fops =3D &sk_proc_fops; - pProcFile->data =3D dev; - } + /* Create proc file */ + if (pSkRootDir &&=20 + (pProcFile =3D create_proc_entry(dev->name, S_IRUGO, + pSkRootDir))) { + pProcFile->proc_fops =3D &sk_proc_fops; + pProcFile->data =3D dev; + } =20 #endif =20 - pNet->PortNr =3D 0; - pNet->NetNr =3D 0; + pNet->PortNr =3D 0; + pNet->NetNr =3D 0; =20 - boards_found++; + boards_found++; =20 - /* More then one port found */ - if ((pAC->GIni.GIMacsFound =3D=3D 2 ) && (pAC->RlmtNets =3D=3D 2)) { - if ((dev =3D alloc_etherdev(sizeof(DEV_NET))) =3D=3D 0) { - printk(KERN_ERR "Unable to allocate etherdev " - "structure!\n"); - break; - } + /* More then one port found */ + if ((pAC->GIni.GIMacsFound =3D=3D 2 ) && (pAC->RlmtNets =3D=3D 2)) { + if ((dev =3D alloc_etherdev(sizeof(DEV_NET))) =3D=3D 0) { + printk(KERN_ERR "Unable to allocate etherdev second" + "structure!\n"); + goto skip; + } =20 - pAC->dev[1] =3D dev; - pNet =3D dev->priv; - pNet->PortNr =3D 1; - pNet->NetNr =3D 1; - pNet->pAC =3D pAC; - pNet->Mtu =3D 1500; - pNet->Up =3D 0; - - dev->open =3D &SkGeOpen; - dev->stop =3D &SkGeClose; - dev->hard_start_xmit =3D &SkGeXmit; - dev->get_stats =3D &SkGeStats; - dev->last_stats =3D &SkGeStats; - dev->set_multicast_list =3D &SkGeSetRxMode; - dev->set_mac_address =3D &SkGeSetMacAddr; - dev->do_ioctl =3D &SkGeIoctl; - dev->change_mtu =3D &SkGeChangeMtu; - dev->flags &=3D ~IFF_RUNNING; + pAC->dev[1] =3D dev; + pNet =3D dev->priv; + pNet->PortNr =3D 1; + pNet->NetNr =3D 1; + pNet->pAC =3D pAC; + pNet->Mtu =3D 1500; + pNet->Up =3D 0; + + dev->open =3D &SkGeOpen; + dev->stop =3D &SkGeClose; + dev->hard_start_xmit =3D &SkGeXmit; + dev->get_stats =3D &SkGeStats; + dev->last_stats =3D &SkGeStats; + dev->set_multicast_list =3D &SkGeSetRxMode; + dev->set_mac_address =3D &SkGeSetMacAddr; + dev->do_ioctl =3D &SkGeIoctl; + dev->change_mtu =3D &SkGeChangeMtu; + dev->flags &=3D ~IFF_RUNNING; =20 #ifdef SK_ZEROCOPY #ifdef USE_SK_TX_CHECKSUM - if (pAC->ChipsetType) { - /* SG and ZEROCOPY - fly baby... */ - dev->features |=3D NETIF_F_SG | NETIF_F_IP_CSUM; - } + if (pAC->ChipsetType) { + /* SG and ZEROCOPY - fly baby... */ + dev->features |=3D NETIF_F_SG | NETIF_F_IP_CSUM; + } #endif #endif =20 - if (register_netdev(dev)) { - printk(KERN_ERR "SKGE: Could not register device.\n"); - free_netdev(dev); - pAC->dev[1] =3D pAC->dev[0]; - } else { + if (register_netdev(dev)) { + printk(KERN_ERR "SKGE: Could not register device.\n"); + free_netdev(dev); + pAC->dev[1] =3D pAC->dev[0]; + } else { #ifdef CONFIG_PROC_FS - if (pSkRootDir=20 - && (pProcFile =3D create_proc_entry(dev->name,=20 - S_IRUGO, pSkRootDir))) { - pProcFile->proc_fops =3D &sk_proc_fops; - pProcFile->data =3D dev; - } + if (pSkRootDir=20 + && (pProcFile =3D create_proc_entry(dev->name,=20 + S_IRUGO, pSkRootDir))) { + pProcFile->proc_fops =3D &sk_proc_fops; + pProcFile->data =3D dev; + } #endif =20 memcpy((caddr_t) &dev->dev_addr, - (caddr_t) &pAC->Addr.Net[1].CurrentMacAddress, 6); + (caddr_t) &pAC->Addr.Net[1].CurrentMacAddress, 6); =09 printk("%s: %s\n", dev->name, pAC->DeviceStr); printk(" PrefPort:B RlmtMode:Dual Check Link State\n"); - } } - - /* Save the hardware revision */ - pAC->HWRevision =3D (((pAC->GIni.GIPciHwRev >> 4) & 0x0F)*10) + - (pAC->GIni.GIPciHwRev & 0x0F); - - /* Set driver globals */ - pAC->Pnmi.pDriverFileName =3D DRIVER_FILE_NAME; - pAC->Pnmi.pDriverReleaseDate =3D DRIVER_REL_DATE; - - SK_MEMSET(&(pAC->PnmiBackup), 0, sizeof(SK_PNMI_STRUCT_DATA)); - SK_MEMCPY(&(pAC->PnmiBackup), &(pAC->PnmiStruct),=20 - sizeof(SK_PNMI_STRUCT_DATA)); - - /* - * This is bollocks, but we need to tell the net-init - * code that it shall go for the next device. - */ -#ifndef MODULE - dev->base_addr =3D 0; -#endif } =20 - /* - * If we're at this point we're going through skge_probe() for - * the first time. Return success (0) if we've initialized 1 - * or more boards. Otherwise, return failure (-ENODEV). - */ + skip: + /* Save the hardware revision */ + pAC->HWRevision =3D (((pAC->GIni.GIPciHwRev >> 4) & 0x0F)*10) + + (pAC->GIni.GIPciHwRev & 0x0F); + + /* Set driver globals */ + pAC->Pnmi.pDriverFileName =3D DRIVER_FILE_NAME; + pAC->Pnmi.pDriverReleaseDate =3D DRIVER_REL_DATE; + + SK_MEMSET(&(pAC->PnmiBackup), 0, sizeof(SK_PNMI_STRUCT_DATA)); + SK_MEMCPY(&(pAC->PnmiBackup), &(pAC->PnmiStruct),=20 + sizeof(SK_PNMI_STRUCT_DATA)); + + return 0; =20 - return boards_found; -} /* skge_probe */ + free_dev_err: + pci_set_drvdata(pdev, NULL); + free_netdev(dev); + err_out: + return retval; +} =20 =20 /*************************************************************************= **** @@ -755,9 +741,6 @@ static char *RlmtMode[SK_MAX_CARD_PARAM] =3D {"", }; #endif =20 -static int debug =3D 0; /* not used */ -static int options[SK_MAX_CARD_PARAM] =3D {0, }; /* not used */ - static int IntsPerSec[SK_MAX_CARD_PARAM]; static char *Moderation[SK_MAX_CARD_PARAM]; static char *ModerationMask[SK_MAX_CARD_PARAM]; @@ -765,12 +748,72 @@ static char *Stats[SK_MAX_CARD_PARAM]; =20 =20 +static void __devexit skge_remove_one(struct pci_dev *pdev) +{ + struct SK_NET_DEVICE *dev =3D pci_get_drvdata(pdev); + DEV_NET *pNet =3D dev->priv; + SK_AC *pAC =3D pNet->pAC; + unsigned long Flags; + SK_EVPARA EvPara; + + netif_stop_queue(SkGeRootDev); + SkGeYellowLED(pAC, pAC->IoBase, 0); + + if(pAC->BoardLevel =3D=3D SK_INIT_RUN) { + /* board is still alive */ + spin_lock_irqsave(&pAC->SlowPathLock, Flags); + EvPara.Para32[0] =3D 0; + EvPara.Para32[1] =3D -1; + SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); + EvPara.Para32[0] =3D 1; + EvPara.Para32[1] =3D -1; + SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); + SkEventDispatcher(pAC, pAC->IoBase); + /* disable interrupts */ + SK_OUT32(pAC->IoBase, B0_IMSK, 0); + SkGeDeInit(pAC, pAC->IoBase); + spin_unlock_irqrestore(&pAC->SlowPathLock, Flags); + pAC->BoardLevel =3D SK_INIT_DATA; + /* We do NOT check here, if IRQ was pending, of course*/ + } + + if(pAC->BoardLevel =3D=3D SK_INIT_IO) { + /* board is still alive */ + SkGeDeInit(pAC, pAC->IoBase); + pAC->BoardLevel =3D SK_INIT_DATA; + } + + if ((pAC->GIni.GIMacsFound =3D=3D 2) && pAC->RlmtNets =3D=3D 2){ + unregister_netdev(pAC->dev[1]); + free_netdev(pAC->dev[1]); + } + + FreeResources(SkGeRootDev); + + SkGeRootDev->get_stats =3D NULL; + /* + * otherwise unregister_netdev calls get_stats with + * invalid IO ... :-( + */ + unregister_netdev(SkGeRootDev); + free_netdev(SkGeRootDev); + kfree(pAC); +} /* skge_remove */ + +static struct pci_driver skge_driver =3D { + .name =3D "skge", + .id_table =3D skge_pci_table, + .probe =3D skge_init_one, + .remove =3D __devexit_p(skge_remove_one), +}; + + /*************************************************************************= **** * * skge_init_module - module initialization function * * Description: - * Very simple, only call skge_probe and return approriate result. + * Very simple, call pci registation * * Returns: * 0, if everything is ok @@ -778,18 +821,7 @@ */ static int __init skge_init_module(void) { - int cards; - SkGeRootDev =3D NULL; -=09 - /* just to avoid warnings ... */ - debug =3D 0; - options[0] =3D 0; - - cards =3D skge_probe(); - if (cards =3D=3D 0) { - printk("sk98lin: No adapter found.\n"); - } - return cards ? 0 : -ENODEV; + return pci_module_init(&skge_driver); } /* skge_init_module */ =20 =20 @@ -805,68 +837,14 @@ */ static void __exit skge_cleanup_module(void) { -DEV_NET *pNet; -SK_AC *pAC; -struct SK_NET_DEVICE *next; -unsigned long Flags; -SK_EVPARA EvPara; - - while (SkGeRootDev) { - pNet =3D (DEV_NET*) SkGeRootDev->priv; - pAC =3D pNet->pAC; - next =3D pAC->Next; - - netif_stop_queue(SkGeRootDev); - SkGeYellowLED(pAC, pAC->IoBase, 0); - - if(pAC->BoardLevel =3D=3D SK_INIT_RUN) { - /* board is still alive */ - spin_lock_irqsave(&pAC->SlowPathLock, Flags); - EvPara.Para32[0] =3D 0; - EvPara.Para32[1] =3D -1; - SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); - EvPara.Para32[0] =3D 1; - EvPara.Para32[1] =3D -1; - SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara); - SkEventDispatcher(pAC, pAC->IoBase); - /* disable interrupts */ - SK_OUT32(pAC->IoBase, B0_IMSK, 0); - SkGeDeInit(pAC, pAC->IoBase); - spin_unlock_irqrestore(&pAC->SlowPathLock, Flags); - pAC->BoardLevel =3D SK_INIT_DATA; - /* We do NOT check here, if IRQ was pending, of course*/ - } - - if(pAC->BoardLevel =3D=3D SK_INIT_IO) { - /* board is still alive */ - SkGeDeInit(pAC, pAC->IoBase); - pAC->BoardLevel =3D SK_INIT_DATA; - } - - if ((pAC->GIni.GIMacsFound =3D=3D 2) && pAC->RlmtNets =3D=3D 2){ - unregister_netdev(pAC->dev[1]); - free_netdev(pAC->dev[1]); - } - - FreeResources(SkGeRootDev); - - SkGeRootDev->get_stats =3D NULL; - /* - * otherwise unregister_netdev calls get_stats with - * invalid IO ... :-( - */ - unregister_netdev(SkGeRootDev); - free_netdev(SkGeRootDev); - kfree(pAC); - SkGeRootDev =3D next; - } + pci_unregister_driver(&skge_driver); =20 #ifdef CONFIG_PROC_FS /* clear proc-dir */ remove_proc_entry(pSkRootDir->name, proc_net); #endif =20 -} /* skge_cleanup_module */ +} =20 module_init(skge_init_module); module_exit(skge_cleanup_module); --Multipart=_Tue__22_Jun_2004_16_11_30_-0700_8uIkj/kgIxNhFzbe-- From romieu@fr.zoreil.com Tue Jun 22 16:18:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 16:18:45 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MNIfgi008154 for ; Tue, 22 Jun 2004 16:18:42 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5MNFvon028360; Wed, 23 Jun 2004 01:15:57 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5MNFuhZ028359; Wed, 23 Jun 2004 01:15:56 +0200 Date: Wed, 23 Jun 2004 01:15:56 +0200 From: Francois Romieu To: Stephen Hemminger Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] get rid of warnings from 8139too driver Message-ID: <20040623011556.A28140@electric-eye.fr.zoreil.com> References: <20040622135122.05be2be1@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040622135122.05be2be1@dell_ss3.pdx.osdl.net>; from shemminger@osdl.org on Tue, Jun 22, 2004 at 01:51:22PM -0700 X-Organisation: Land of Sunshine Inc. X-archive-position: 6265 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 Stephen Hemminger : > Get rid of sparse warnings from 8139too driver. > * move start_thread which was inline into the open routine (only place called). I can understand that rtl8139_start_thread() appears a bit late in the file but I appreciate the virtues of helpers functions as they document what the code is supposed to achieve. Just mho of course. -- Ueimor From jgarzik@pobox.com Tue Jun 22 16:23:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 16:23: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.12.10/8.12.9) with SMTP id i5MNNTgi011780 for ; Tue, 22 Jun 2004 16:23:32 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bcubw-0006uT-BV; Wed, 23 Jun 2004 00:23:28 +0100 Message-ID: <40D8BF63.9010308@pobox.com> Date: Tue, 22 Jun 2004 19:23:15 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Mirko Lindner , Ralph Roesler , netdev@oss.sgi.com, Christoph Hellwig Subject: Re: [RFT] convert syskonnect gigabit ether driver to PCI module interface References: <20040622161130.0adaac78@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622161130.0adaac78@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6266 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 Stephen Hemminger wrote: > This patch converts the SysKonnect Gigabit Ethernet (Yukon) driver from > the old pci_find_class infrastructure, to the current 2.4/2.6 pci_module probing > model. The device identification is no longer done in the macro, but in a pci_device_id > table like other drivers. Didn't Christoph just submit this same patch? :) Jeff From davem@redhat.com Tue Jun 22 17:10:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 17:10:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N0A8gi013501 for ; Tue, 22 Jun 2004 17:10: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 i5N0A5e1015311; Tue, 22 Jun 2004 20:10:05 -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 i5N0A4004597; Tue, 22 Jun 2004 20:10: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 i5N09hXQ009162; Tue, 22 Jun 2004 20:09:44 -0400 Date: Tue, 22 Jun 2004 17:09:46 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] rtentry->rt_dev is __user Message-Id: <20040622170946.193420fc.davem@redhat.com> In-Reply-To: <20040622155453.564ede17@dell_ss3.pdx.osdl.net> References: <20040622155453.564ede17@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: 6267 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 Tue, 22 Jun 2004 15:54:53 -0700 Stephen Hemminger wrote: > The device entry in the route ioctl's needs annotation. > > Signed-off-by: Stephen Hemminger Applied. From davem@redhat.com Tue Jun 22 17:11:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 17:11:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N0Bogi013732 for ; Tue, 22 Jun 2004 17:11:50 -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 i5N0Bme1015674; Tue, 22 Jun 2004 20:11:48 -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 i5N0Bm005233; Tue, 22 Jun 2004 20:11:48 -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 i5N0BRj8010234; Tue, 22 Jun 2004 20:11:27 -0400 Date: Tue, 22 Jun 2004 17:11:29 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] ip_rt_ioctl argument is user pointer Message-Id: <20040622171129.0b353008.davem@redhat.com> In-Reply-To: <20040622160022.75db69bb@dell_ss3.pdx.osdl.net> References: <20040622160022.75db69bb@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: 6268 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 Tue, 22 Jun 2004 16:00:22 -0700 Stephen Hemminger wrote: > The function ip_rt_ioctl expects a pointer to a user route structure, so define > it that way and cast as appropriate. Applied, thanks Stephen. From ganesh.venkatesan@intel.com Tue Jun 22 19:52:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 19:53:03 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N2qwgi016849 for ; Tue, 22 Jun 2004 19:52:58 -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 i5LJ6IkS027091; Mon, 21 Jun 2004 19:06:19 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5LJ1cLp018021; Mon, 21 Jun 2004 19:01:45 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062112062310990 ; Mon, 21 Jun 2004 12:06:23 -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); Mon, 21 Jun 2004 12:06:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delayscheduler Date: Mon, 21 Jun 2004 12:06:08 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E017BA1BB@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delayscheduler Thread-Index: AcRXvsvUQ+FGTuzTTVy4BP7B1t73GwAA+Q2A From: "Venkatesan, Ganesh" To: , "David Greaves" Cc: "Jens Laas" , "Stephen Hemminger" , X-OriginalArrivalTime: 21 Jun 2004 19:06:09.0293 (UTC) FILETIME=[CFB05BD0:01C457C2] 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 i5N2qwgi016849 X-archive-position: 6269 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 Thayne: David did disable DITR and his problem did not go away. So, he is definitely seeing a different issue. Thanks, ganesh ------------------------------------------------- Ganesh Venkatesan Network/Storage Division, Hillsboro, OR -----Original Message----- From: Thayne Harbaugh [mailto:tharbaugh@lnxi.com] Sent: Monday, June 21, 2004 11:25 AM To: David Greaves Cc: Jens Laas; Stephen Hemminger; netdev@oss.sgi.com; Venkatesan, Ganesh Subject: Re: 2.6.6 e1000 NETDEV WATCHDOG: eth0: transmit timed out+ delayscheduler On Mon, 2004-06-21 at 11:29, David Greaves wrote: > Thayne Harbaugh wrote: > > >On Fri, 2004-06-18 at 03:08, David Greaves wrote: > > > >>Jens Laas wrote: > >> > >>>We have tried different versions of e1000 without luck. > >>> > >>> > >>Me too, 3 cards. > >>(did I mention I have 2 machines with very similar specs (AMD/VIAKT600) > >>and the other one works - actually, to be accurate, hasn't yet failed > >>but hasn't yet run at full speed - and it has a higher CPU speed) > >> > >> > > > >What do you mean by, ". . . hasn't yet run at full speed - and it has a > >higher CPU speed . . ." ? Does this mean that you can't get the card to > >have a reasonable throughput (~900Mbps)? > > > > It sounded reasonable when I wrote it :) > > I have 2 machines I can easily test with (wired back to back) > Machine 1 has an AMD3000+ CPU, machine 2 has an AMD3200+ cpu (maybe not > relevant - maybe important if it's timing related?) > > Machine one stalls within a few kb. > Machine two has shown no signs of failure yet. > > However the other machine has not been stressed at all so it has 'not > yet run at full speed' - not surprising since it has no friends with > working gigabit cards :) I have found a problem where the e1000 driver doesn't allow the hardware to "run at full speed." I think, however, that it is a different problem than what you have found. The dynamic interrupt throttling (DITR) code in the 5.x e1000 drivers is horribly broken and throttles interrupts (and therefore throughput) even when there are plenty of resources for handling the interrupts and throughput. Consequently the performance is ~350Mbps when it should be ~900Mbps. If you ever get your cards working correctly and are interested to get the best performance then send me an email. Alternatively, you can search for my posts in the archives. -- Thayne Harbaugh Linux Networx From mcgrof@studorgs.rutgers.edu Tue Jun 22 22:43:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 22:44:16 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N5hngi024536 for ; Tue, 22 Jun 2004 22:43:50 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 900C5F9D4E; Wed, 23 Jun 2004 01:43:48 -0400 (EDT) Date: Wed, 23 Jun 2004 01:43:48 -0400 From: mcgrof@studorgs.rutgers.edu To: Andrew Morton Cc: Netdev , Linux Kernel , Jeff Garzik , prism54-devel@prism54.org Subject: [PATCH 2.4.26] prism54: add prism54 1.2 Message-ID: <20040623054348.GV6253@ruslug.rutgers.edu> Mail-Followup-To: Andrew Morton , Netdev , Linux Kernel , Jeff Garzik , prism54-devel@prism54.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4T94Hejb80K+e1gX" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group X-archive-position: 6270 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 --4T94Hejb80K+e1gX Content-Type: multipart/mixed; boundary="9pS2hy4/DrI8BQlq" Content-Disposition: inline --9pS2hy4/DrI8BQlq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andrew, 2.6.7-bk5 and 2.6.7-mm1 are both in perfect sync with prism54=20 cvs tree now. This completes our 1.2 release. As promised,=20 the attached patch adds prism54 1.2 to 2.4 kernel tree. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --9pS2hy4/DrI8BQlq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.4.26-prism54.diff" Content-Transfer-Encoding: quoted-printable --- linux-2.4.26/Documentation/Configure.help 2004-04-14 13:05:24.000000000= +0000 +++ linux-2.4.26-prism54/Documentation/Configure.help 2004-06-23 05:30:04.0= 00000000 +0000 @@ -9968,6 +9968,49 @@ compile it as a module, say M here and read . =20 +Intersil 802.11(a/b/g) Prism GT/Duette/Indigo support +CONFIG_PRISM54 + Enable PCI and Cardbus support for the following chipset based cards: + + ISL3880 - Prism GT 802.11 b/g + ISL3877 - Prism Indigo 802.11 a + ISL3890 - Prism Duette 802.11 a/b/g + =20 + For a complete list of supported cards visit . + Here is the latest confirmed list of supported cards: + + 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 + Allnet ALL0271 PCI Card + Compex WL54G Cardbus Card + Corega CG-WLCB54GT Cardbus Card + D-Link Air Plus Xtreme G A1 Cardbus Card aka DWL-g650 + I-O Data WN-G54/CB Cardbus Card + Kobishi XG-300 aka Z-Com Cardbus Card + Netgear WG511 Cardbus Card + Ovislink WL-5400PCI PCI Card + Peabird WLG-PCI PCI Card + Sitecom WL-100i Cardbus Card + Sitecom WL-110i PCI Card + SMC2802W - EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card + SMC2835W - EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Card + Z-Com XG-900 PCI Card + Zyxel G-100 Cardbus Card + + If you enable this, you require a firmware file as well. + You will need to copy this to /usr/lib/hotplug/firmware/isl3890. + You can get this non-GPL'd firmware file from the Prism54 project page: + . + You will also need the /etc/hotplug/firmware.agent script from + a current hotplug package. + + + Note: You need a motherboard with DMA support to use any of these cards= =20 + =20 + If you want to compile the driver as a module ( =3D code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read . The module + will be called prism54.o. + Aironet 4500/4800 PROC interface CONFIG_AIRONET4500_PROC If you say Y here (and to the "/proc file system" below), you will diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/C= onfig.in linux-2.4.26-prism54/drivers/net/wireless/Config.in --- linux-2.4.26/drivers/net/wireless/Config.in 2004-04-14 13:05:30.0000000= 00 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/Config.in 2004-06-23 05:30:04= .000000000 +0000 @@ -27,6 +27,15 @@ dep_tristate ' Atmel at76c502/at76c504 PCMCIA cards' CONFIG_PCMCIA_ATM= EL $CONFIG_FW_LOADER fi =20 +# If PCI enabled, allow for prism54 driver. CONFIG_FW_LOADER required +comment 'Prism54 PCI/PCMCIA GT/Duette Driver - 802.11(a/b/g)' +dep_tristate 'Intersil Prism GT/Duette/Indigo PCI/PCMCIA' CONFIG_PRISM54 $= CONFIG_EXPERIMENTAL $CONFIG_PCI $CONFIG_HOTPLUG +if [ "$CONFIG_PRISM54" !=3D "n" ]; then + if [ "$CONFIG_FW_LOADER" !=3D "y" ]; then + define_tristate CONFIG_FW_LOADER $CONFIG_PRISM54 + fi +fi + # yes, this works even when no drivers are selected if [ "$CONFIG_ISA" =3D "y" -o "$CONFIG_PCI" =3D "y" -o \ "$CONFIG_ALL_PPC" =3D "y" -o "$CONFIG_PCMCIA" !=3D "n" ]; then diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/M= akefile linux-2.4.26-prism54/drivers/net/wireless/Makefile --- linux-2.4.26/drivers/net/wireless/Makefile 2004-04-14 13:05:30.00000000= 0 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/Makefile 2004-06-23 05:30:04.= 000000000 +0000 @@ -25,4 +25,9 @@ obj-$(CONFIG_AIRO_CS) +=3D airo_cs.o airo.o obj-$(CONFIG_PCMCIA_ATMEL) +=3D atmel_cs.o atmel.o =20 +ifeq ($(CONFIG_PRISM54),y) +obj-$(CONFIG_PRISM54) +=3D prism54/prism54.o +endif +subdir-$(CONFIG_PRISM54) +=3D prism54 + include $(TOPDIR)/Rules.make diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/Makefile linux-2.4.26-prism54/drivers/net/wireless/prism54/Makefile --- linux-2.4.26/drivers/net/wireless/prism54/Makefile 1970-01-01 00:00:00.= 000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/Makefile 2004-06-23 0= 5:30:04.000000000 +0000 @@ -0,0 +1,12 @@ + +O_TARGET :=3D prism54.o + +EXTRA_CFLAGS +=3D -DPRISM54_COMPAT24 + +obj-y :=3D isl_38xx.o islpci_dev.o islpci_eth.o \ + islpci_mgt.o islpci_hotplug.o isl_ioctl.o \ + oid_mgt.o + +obj-m +=3D prism54.o + +include $(TOPDIR)/Rules.make diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_38xx.c linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38x= x.c --- linux-2.4.26/drivers/net/wireless/prism54/isl_38xx.c 1970-01-01 00:00:0= 0.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38xx.c 2004-06-23= 05:30:04.000000000 +0000 @@ -0,0 +1,267 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003-2004 Luis R. Rodriguez _ + * + * 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 + * + * 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 + * + */ + +#define __KERNEL_SYSCALLS__ + +#include +#include +#include +#include + +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" + +/*************************************************************************= ***** + Device Interface & Control functions +**************************************************************************= ****/ + +/** + * isl38xx_disable_interrupts - disable all interrupts + * @device: pci memory base address + * + * Instructs the device to disable all interrupt reporting by asserting= =20 + * the IRQ line. New events may still show up in the interrupt identifica= tion + * register located at offset %ISL38XX_INT_IDENT_REG. + */ +void +isl38xx_disable_interrupts(void *device) +{ + isl38xx_w32_flush(device, 0x00000000, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_handle_sleep_request(isl38xx_control_block *control_block, + int *powerstate, void *device_base) +{ + /* device requests to go into sleep mode + * check whether the transmit queues for data and management are empty */ + if (isl38xx_in_queue(control_block, ISL38XX_CB_TX_DATA_LQ)) + /* data tx queue not empty */ + return; + + if (isl38xx_in_queue(control_block, ISL38XX_CB_TX_MGMTQ)) + /* management tx queue not empty */ + return; + + /* check also whether received frames are pending */ + if (isl38xx_in_queue(control_block, ISL38XX_CB_RX_DATA_LQ)) + /* data rx queue not empty */ + return; + + if (isl38xx_in_queue(control_block, ISL38XX_CB_RX_MGMTQ)) + /* management rx queue not empty */ + return; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Device going to sleep mode\n"); +#endif + + /* all queues are empty, allow the device to go into sleep mode */ + *powerstate =3D ISL38XX_PSM_POWERSAVE_STATE; + + /* assert the Sleep interrupt in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_SLEEP, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_handle_wakeup(isl38xx_control_block *control_block, + int *powerstate, void *device_base) +{ + /* device is in active state, update the powerstate flag */ + *powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* now check whether there are frames pending for the card */ + if (!isl38xx_in_queue(control_block, ISL38XX_CB_TX_DATA_LQ) + && !isl38xx_in_queue(control_block, ISL38XX_CB_TX_MGMTQ)) + return; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_ANYTHING, "Wake up handler trigger the device\n"); +#endif + + /* either data or management transmit queue has a frame pending + * trigger the device by setting the Update bit in the Device Int reg */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_trigger_device(int asleep, void *device_base) +{ + struct timeval current_time; + u32 reg, counter =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "isl38xx trigger device\n"); +#endif + + /* check whether the device is in power save mode */ + if (asleep) { + /* device is in powersave, trigger the device for wakeup */ +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", + current_time.tv_sec, current_time.tv_usec); +#endif + + DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, + readl(device_base + ISL38XX_CTRL_STAT_REG)); + udelay(ISL38XX_WRITEIO_DELAY); + + if (reg =3D readl(device_base + ISL38XX_INT_IDENT_REG), + reg =3D=3D 0xabadface) { +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, + "%08li.%08li Device register abadface\n", + current_time.tv_sec, current_time.tv_usec); +#endif + /* read the Device Status Register until Sleepmode bit is set */ + while (reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG), + (reg & ISL38XX_CTRL_STAT_SLEEPMODE) =3D=3D 0) { + udelay(ISL38XX_WRITEIO_DELAY); + counter++; + } + + DEBUG(SHOW_TRACING, + "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, + readl(device_base + ISL38XX_CTRL_STAT_REG)); + udelay(ISL38XX_WRITEIO_DELAY); + +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, + "%08li.%08li Device asleep counter %i\n", + current_time.tv_sec, current_time.tv_usec, + counter); +#endif + } + /* assert the Wakeup interrupt in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_WAKEUP, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* perform another read on the Device Status Register */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, reg); +#endif + } else { + /* device is (still) awake */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Device is in active state\n"); +#endif + /* trigger the device by setting the Update bit in the Device Int reg */ + + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + } +} + +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"); +#endif + + /* load the address of the control block in the device */ + isl38xx_w32_flush(device_base, host_address, ISL38XX_CTRL_BLK_BASE_REG); + 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); + udelay(ISL38XX_WRITEIO_DELAY); + + /* enable the interrupt for detecting initialization */ + + /* Note: Do not enable other interrupts here. We want the + * device to have come up first 100% before allowing any other=20 + * interrupts. */ + reg =3D ISL38XX_INT_IDENT_INIT; + + isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); /* allow complete full reset */ +} + +void +isl38xx_enable_common_interrupts(void *device_base) { + u32 reg; + reg =3D ( ISL38XX_INT_IDENT_UPDATE |=20 + ISL38XX_INT_IDENT_SLEEP | ISL38XX_INT_IDENT_WAKEUP); + isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +int +isl38xx_in_queue(isl38xx_control_block *cb, int queue) +{ + const s32 delta =3D (le32_to_cpu(cb->driver_curr_frag[queue]) - + le32_to_cpu(cb->device_curr_frag[queue])); + + /* determine the amount of fragments in the queue depending on the type + * of the queue, either transmit or receive */ + + BUG_ON(delta < 0); /* driver ptr must be ahead of device ptr */ + + switch (queue) { + /* send queues */ + case ISL38XX_CB_TX_MGMTQ: + BUG_ON(delta > ISL38XX_CB_MGMT_QSIZE); + case ISL38XX_CB_TX_DATA_LQ: + case ISL38XX_CB_TX_DATA_HQ: + BUG_ON(delta > ISL38XX_CB_TX_QSIZE); + return delta; + break; + + /* receive queues */ + case ISL38XX_CB_RX_MGMTQ: + BUG_ON(delta > ISL38XX_CB_MGMT_QSIZE); + return ISL38XX_CB_MGMT_QSIZE - delta; + break; + + case ISL38XX_CB_RX_DATA_LQ: + case ISL38XX_CB_RX_DATA_HQ: + BUG_ON(delta > ISL38XX_CB_RX_QSIZE); + return ISL38XX_CB_RX_QSIZE - delta; + break; + } + BUG(); + return 0; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_38xx.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38x= x.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_38xx.h 1970-01-01 00:00:0= 0.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38xx.h 2004-06-23= 05:30:04.000000000 +0000 @@ -0,0 +1,169 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * + * 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 + * + * 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 _ISL_38XX_H +#define _ISL_38XX_H + +#include +#include +#include + +#define ISL38XX_CB_RX_QSIZE 8 +#define ISL38XX_CB_TX_QSIZE 32 + +/* ISL38XX Access Point Specific definitions */ +#define ISL38XX_MAX_WDS_LINKS 8 + +/* ISL38xx Client Specific definitions */ +#define ISL38XX_PSM_ACTIVE_STATE 0 +#define ISL38XX_PSM_POWERSAVE_STATE 1 + +/* ISL38XX Host Interface Definitions */ +#define ISL38XX_PCI_MEM_SIZE 0x02000 +#define ISL38XX_MEMORY_WINDOW_SIZE 0x01000 +#define ISL38XX_DEV_FIRMWARE_ADDRES 0x20000 +#define ISL38XX_WRITEIO_DELAY 10 /* in us */ +#define ISL38XX_RESET_DELAY 50 /* in ms */ +#define ISL38XX_WAIT_CYCLE 10 /* in 10ms */ +#define ISL38XX_MAX_WAIT_CYCLES 10 + +/* PCI Memory Area */ +#define ISL38XX_HARDWARE_REG 0x0000 +#define ISL38XX_CARDBUS_CIS 0x0800 +#define ISL38XX_DIRECT_MEM_WIN 0x1000 + +/* Hardware registers */ +#define ISL38XX_DEV_INT_REG 0x0000 +#define ISL38XX_INT_IDENT_REG 0x0010 +#define ISL38XX_INT_ACK_REG 0x0014 +#define ISL38XX_INT_EN_REG 0x0018 +#define ISL38XX_GEN_PURP_COM_REG_1 0x0020 +#define ISL38XX_GEN_PURP_COM_REG_2 0x0024 +#define ISL38XX_CTRL_BLK_BASE_REG ISL38XX_GEN_PURP_COM_REG_1 +#define ISL38XX_DIR_MEM_BASE_REG 0x0030 +#define ISL38XX_CTRL_STAT_REG 0x0078 + +/* High end mobos queue up pci writes, the following + * is used to "read" from after a write to force flush */ +#define ISL38XX_PCI_POSTING_FLUSH ISL38XX_INT_EN_REG + +/** + * isl38xx_w32_flush - PCI iomem write helper + * @base: (host) memory base address of the device + * @val: 32bit value (host order) to write + * @offset: byte offset into @base to write value to + *=20 + * This helper takes care of writing a 32bit datum to the + * specified offset into the device's pci memory space, and making sure= =20 + * the pci memory buffers get flushed by performing one harmless read=20 + * from the %ISL38XX_PCI_POSTING_FLUSH offset. + */ +static inline void +isl38xx_w32_flush(void *base, u32 val, unsigned long offset) +{ + writel(val, base + offset); + (void) readl(base + ISL38XX_PCI_POSTING_FLUSH); +} + +/* Device Interrupt register bits */ +#define ISL38XX_DEV_INT_RESET 0x0001 +#define ISL38XX_DEV_INT_UPDATE 0x0002 +#define ISL38XX_DEV_INT_WAKEUP 0x0008 +#define ISL38XX_DEV_INT_SLEEP 0x0010 + +/* Interrupt Identification/Acknowledge/Enable register bits */ +#define ISL38XX_INT_IDENT_UPDATE 0x0002 +#define ISL38XX_INT_IDENT_INIT 0x0004 +#define ISL38XX_INT_IDENT_WAKEUP 0x0008 +#define ISL38XX_INT_IDENT_SLEEP 0x0010 +#define ISL38XX_INT_SOURCES 0x001E + +/* Control/Status register bits */ +#define ISL38XX_CTRL_STAT_SLEEPMODE 0x00000200 +#define ISL38XX_CTRL_STAT_CLKRUN 0x00800000 +#define ISL38XX_CTRL_STAT_RESET 0x10000000 +#define ISL38XX_CTRL_STAT_RAMBOOT 0x20000000 +#define ISL38XX_CTRL_STAT_STARTHALTED 0x40000000 +#define ISL38XX_CTRL_STAT_HOST_OVERRIDE 0x80000000 + +/* Control Block definitions */ +#define ISL38XX_CB_RX_DATA_LQ 0 +#define ISL38XX_CB_TX_DATA_LQ 1 +#define ISL38XX_CB_RX_DATA_HQ 2 +#define ISL38XX_CB_TX_DATA_HQ 3 +#define ISL38XX_CB_RX_MGMTQ 4 +#define ISL38XX_CB_TX_MGMTQ 5 +#define ISL38XX_CB_QCOUNT 6 +#define ISL38XX_CB_MGMT_QSIZE 4 +#define ISL38XX_MIN_QTHRESHOLD 4 /* fragments */ + +/* Memory Manager definitions */ +#define MGMT_FRAME_SIZE 1500 /* >=3D size struct o= bj_bsslist */ +#define MGMT_TX_FRAME_COUNT 24 /* max 4 + spare 4 + 8 = init */ +#define MGMT_RX_FRAME_COUNT 24 /* 4*4 + spare 8 */ +#define MGMT_FRAME_COUNT (MGMT_TX_FRAME_COUNT + MGM= T_RX_FRAME_COUNT) +#define CONTROL_BLOCK_SIZE 1024 /* should be enough */ +#define PSM_FRAME_SIZE 1536 +#define PSM_MINIMAL_STATION_COUNT 64 +#define PSM_FRAME_COUNT PSM_MINIMAL_STATION_COUNT +#define PSM_BUFFER_SIZE PSM_FRAME_SIZE * PSM_FRAME= _COUNT +#define MAX_TRAP_RX_QUEUE 4 +#define HOST_MEM_BLOCK CONTROL_BLOCK_SIZE + PSM_B= UFFER_SIZE + +/* Fragment package definitions */ +#define FRAGMENT_FLAG_MF 0x0001 +#define MAX_FRAGMENT_SIZE 1536 + +/* In monitor mode frames have a header. I don't know exactly how big those + * frame can be but I've never seen any frame bigger than 1584... : + */ +#define MAX_FRAGMENT_SIZE_RX 1600 + +typedef struct { + u32 address; /* physical address on host */ + u16 size; /* packet size */ + u16 flags; /* set of bit-wise flags */ +} isl38xx_fragment; + +struct isl38xx_cb { + u32 driver_curr_frag[ISL38XX_CB_QCOUNT]; + u32 device_curr_frag[ISL38XX_CB_QCOUNT]; + isl38xx_fragment rx_data_low[ISL38XX_CB_RX_QSIZE]; + isl38xx_fragment tx_data_low[ISL38XX_CB_TX_QSIZE]; + isl38xx_fragment rx_data_high[ISL38XX_CB_RX_QSIZE]; + isl38xx_fragment tx_data_high[ISL38XX_CB_TX_QSIZE]; + isl38xx_fragment rx_data_mgmt[ISL38XX_CB_MGMT_QSIZE]; + isl38xx_fragment tx_data_mgmt[ISL38XX_CB_MGMT_QSIZE]; +}; + +typedef struct isl38xx_cb isl38xx_control_block; + +/* determine number of entries currently in queue */ +int isl38xx_in_queue(isl38xx_control_block *cb, int queue); + +void isl38xx_disable_interrupts(void *); +void isl38xx_enable_common_interrupts(void *); + +void isl38xx_handle_sleep_request(isl38xx_control_block *, int *, + void *); +void isl38xx_handle_wakeup(isl38xx_control_block *, int *, void *); +void isl38xx_trigger_device(int, void *); +void isl38xx_interface_reset(void *, dma_addr_t); + +#endif /* _ISL_38XX_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_ioctl.c linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_io= ctl.c --- linux-2.4.26/drivers/net/wireless/prism54/isl_ioctl.c 1970-01-01 00:00:= 00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-2= 3 05:30:04.000000000 +0000 @@ -0,0 +1,2261 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * (C) 2003,2004 Aurelien Alleaume + * (C) 2003 Herbert Valerio Riedel + * (C) 2003 Luis R. Rodriguez + * + * 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 + * + * 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 "prismcompat.h" +#include "isl_ioctl.h" +#include "islpci_mgt.h" +#include "isl_oid.h" /* additional types and defs for isl38xx fw */ +#include "oid_mgt.h" + +#include /* New driver API */ + +static int init_mode =3D CARD_DEFAULT_IW_MODE; +static int init_channel =3D CARD_DEFAULT_CHANNEL; +static int init_wep =3D CARD_DEFAULT_WEP; +static int init_filter =3D CARD_DEFAULT_FILTER; +static int init_authen =3D CARD_DEFAULT_AUTHEN; +static int init_dot1x =3D CARD_DEFAULT_DOT1X; +static int init_conformance =3D CARD_DEFAULT_CONFORMANCE; +static int init_mlme =3D 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: Ma= ster / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not sup= ported 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 0x000= 1: DOT11_AUTH_OS (Default)\n2 0x0002: DOT11_AUTH_SK\n3 0x0003: DOT11_AUTH_B= OTH"); + +module_param(init_dot1x, int, 0); +MODULE_PARM_DESC(init_dot1x, + "\n0: None/not set (Default)\n1: DOT11_DOT1X_AUTHENABLED\n2: DOT11_DOT1= X_KEYTXENABLED"); + +module_param(init_mlme, int, 0); +MODULE_PARM_DESC(init_mlme, + "Sets the MAC layer management entity (MLME) mode of operation,\n0: DOT= 11_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 + * @iw_mode: new mode (%IW_MODE_*) + *=20 + * This is a helper function, hence it does not lock. Make sure + * caller deals with locking *if* necessary. This function sets the=20 + * mode-dependent mib values and does the mapping of the Linux=20 + * Wireless API modes to Device firmware modes. It also checks for=20 + * correct valid Linux wireless modes.=20 + */ +int +prism54_mib_mode_helper(islpci_private *priv, u32 iw_mode) +{ + u32 config =3D INL_CONFIG_MANUALRUN; + u32 mode, bsstype; + + /* For now, just catch early the Repeater and Secondary modes here */ + if (iw_mode =3D=3D IW_MODE_REPEAT || iw_mode =3D=3D IW_MODE_SECOND) { + printk(KERN_DEBUG + "%s(): Sorry, Repeater mode and Secondary mode " + "are not yet supported by this driver.\n", __FUNCTION__); + return -EINVAL; + } + + priv->iw_mode =3D iw_mode; + + switch (iw_mode) { + case IW_MODE_AUTO: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_ANY; + break; + case IW_MODE_ADHOC: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_IBSS; + break; + case IW_MODE_INFRA: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_INFRA; + break; + case IW_MODE_MASTER: + mode =3D INL_MODE_AP; + bsstype =3D DOT11_BSSTYPE_INFRA; + break; + case IW_MODE_MONITOR: + mode =3D INL_MODE_PROMISCUOUS; + bsstype =3D DOT11_BSSTYPE_ANY; + config |=3D INL_CONFIG_RXANNEX; + break; + default: + return -EINVAL; + } + + if (init_wds) + config |=3D INL_CONFIG_WDS; + mgt_set(priv, DOT11_OID_BSSTYPE, &bsstype); + mgt_set(priv, OID_INL_CONFIG, &config); + mgt_set(priv, OID_INL_MODE, &mode); + + return 0; +} + +/** + * prism54_mib_init - fill MIB cache with defaults + * + * this function initializes the struct given as @mib with defaults, + * of which many are retrieved from the global module parameter + * variables. =20 + */ + +void +prism54_mib_init(islpci_private *priv) +{ + u32 t; + struct obj_buffer psm_buffer =3D { + .size =3D PSM_BUFFER_SIZE, + .addr =3D 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); + + 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 =3D 127; + mgt_set(priv, OID_INL_OUTPUTPOWER, &t); + + /* Important: we are setting a default wireless mode and we are=20 + * 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 =3D CARD_DEFAULT_IW_MODE; + } + /* This sets all of the mode-dependent values */ + prism54_mib_mode_helper(priv, init_mode); +} + +/* this will be executed outside of atomic context thanks to + * schedule_work(), thus we can as well use sleeping semaphore + * locking */ +void +prism54_update_stats(islpci_private *priv) +{ + char *data; + int j; + struct obj_bss bss, *bss2; + union oid_res_t r; + + if (down_interruptible(&priv->stats_sem)) + return; + +/* Noise floor. + * I'm not sure if the unit is dBm. + * Note : If we are not connected, this value seems to be irrelevant. */ + + mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + priv->local_iwstatistics.qual.noise =3D r.u; + +/* Get the rssi of the link. To do this we need to retrieve a bss. */ + + /* First get the MAC address of the AP we are associated with. */ + mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); + data =3D r.ptr; + + /* copy this MAC to the bss */ + memcpy(bss.address, data, 6); + kfree(data); + + /* now ask for the corresponding bss */ + j =3D mgt_get_request(priv, DOT11_OID_BSSFIND, 0, (void *) &bss, &r); + bss2 =3D r.ptr; + /* report the rssi and use it to calculate + * link quality through a signal-noise + * ratio */ + priv->local_iwstatistics.qual.level =3D bss2->rssi; + priv->local_iwstatistics.qual.qual =3D + bss2->rssi - priv->iwstatistics.qual.noise; + + kfree(bss2); + + /* report that the stats are new */ + priv->local_iwstatistics.qual.updated =3D 0x7; + +/* Rx : unable to decrypt the MPDU */ + mgt_get_request(priv, DOT11_OID_PRIVRXFAILED, 0, NULL, &r); + priv->local_iwstatistics.discard.code =3D r.u; + +/* Tx : Max MAC retries num reached */ + mgt_get_request(priv, DOT11_OID_MPDUTXFAILED, 0, NULL, &r); + priv->local_iwstatistics.discard.retries =3D r.u; + + up(&priv->stats_sem); + + return; +} + +struct iw_statistics * +prism54_get_wireless_stats(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + + /* If the stats are being updated return old data */ + if (down_trylock(&priv->stats_sem) =3D=3D 0) { + memcpy(&priv->iwstatistics, &priv->local_iwstatistics, + sizeof (struct iw_statistics)); + /* They won't be marked updated for the next time */ + priv->local_iwstatistics.qual.updated =3D 0; + up(&priv->stats_sem); + } else + priv->iwstatistics.qual.updated =3D 0; + + /* Update our wireless stats, but do not schedule to often=20 + * (max 1 HZ) */ + if ((priv->stats_timestamp =3D=3D 0) || + time_after(jiffies, priv->stats_timestamp + 1 * HZ)) { + schedule_work(&priv->stats_work); + priv->stats_timestamp =3D jiffies; + } + + return &priv->iwstatistics; +} + +static int +prism54_commit(struct net_device *ndev, struct iw_request_info *info, + char *cwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + /* simply re-set the last set SSID, this should commit most stuff */ + + /* Commit in Monitor mode is not necessary, also setting essid + * in Monitor mode does not make sense and isn't allowed for this + * device's firmware */ + if (priv->iw_mode !=3D IW_MODE_MONITOR) + return mgt_set_request(priv, DOT11_OID_SSID, 0, NULL); + return 0; +} + +static int +prism54_get_name(struct net_device *ndev, struct iw_request_info *info, + char *cwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + char *capabilities; + union oid_res_t r; + int rvalue; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + strncpy(cwrq, "NOT READY!", IFNAMSIZ); + return 0; + } + rvalue =3D mgt_get_request(priv, OID_INL_PHYCAPABILITIES, 0, NULL, &r); + + switch (r.u) { + case INL_PHYCAP_5000MHZ: + capabilities =3D "IEEE 802.11a/b/g"; + break; + case INL_PHYCAP_FAA: + capabilities =3D "IEEE 802.11b/g - FAA Support"; + break; + case INL_PHYCAP_2400MHZ: + default: + capabilities =3D "IEEE 802.11b/g"; /* Default */ + break; + } + strncpy(cwrq, capabilities, IFNAMSIZ); + return rvalue; +} + +static int +prism54_set_freq(struct net_device *ndev, struct iw_request_info *info, + struct iw_freq *fwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue; + u32 c; + + if (fwrq->m < 1000) + /* we have a channel number */ + c =3D fwrq->m; + else + c =3D (fwrq->e =3D=3D 1) ? channel_of_freq(fwrq->m / 100000) : 0; + + rvalue =3D c ? mgt_set_request(priv, DOT11_OID_CHANNEL, 0, &c) : -EINVAL; + + /* Call commit handler */ + return (rvalue ? rvalue : -EINPROGRESS); +} + +static int +prism54_get_freq(struct net_device *ndev, struct iw_request_info *info, + struct iw_freq *fwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_CHANNEL, 0, NULL, &r); + + fwrq->m =3D r.u; + fwrq->e =3D 0; + + return rvalue; +} + +static int +prism54_set_mode(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 mlmeautolevel =3D CARD_DEFAULT_MLME_MODE; + + /* Let's see if the user passed a valid Linux Wireless mode */ + if (*uwrq > IW_MODE_MONITOR || *uwrq < IW_MODE_AUTO) { + printk(KERN_DEBUG + "%s: %s() You passed a non-valid init_mode.\n", + priv->ndev->name, __FUNCTION__); + return -EINVAL; + } + + down_write(&priv->mib_sem); + + if (prism54_mib_mode_helper(priv, *uwrq)) { + up_write(&priv->mib_sem); + return -EOPNOTSUPP; + } + + /* the ACL code needs an intermediate mlmeautolevel. The wpa stuff an + * extended one. + */ + if ((*uwrq =3D=3D IW_MODE_MASTER) && (priv->acl.policy !=3D MAC_POLICY_OP= EN)) + mlmeautolevel =3D DOT11_MLME_INTERMEDIATE; + if (priv->wpa) + mlmeautolevel =3D DOT11_MLME_EXTENDED; + + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlmeautolevel); + + mgt_commit(priv); + priv->ndev->type =3D (priv->iw_mode =3D=3D IW_MODE_MONITOR) + ? priv->monitor_type : ARPHRD_ETHER; + up_write(&priv->mib_sem); + + return 0; +} + +/* Use mib cache */ +static int +prism54_get_mode(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + BUG_ON((priv->iw_mode < IW_MODE_AUTO) || (priv->iw_mode > + IW_MODE_MONITOR)); + *uwrq =3D priv->iw_mode; + + return 0; +} + +/* we use DOT11_OID_EDTHRESHOLD. From what I guess the card will not try to + * emit data if (sensitivity > rssi - noise) (in dBm). + * prism54_set_sens does not seem to work. + */ + +static int +prism54_set_sens(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 sens; + + /* by default the card sets this to 20. */ + sens =3D vwrq->disabled ? 20 : vwrq->value; + + return mgt_set_request(priv, DOT11_OID_EDTHRESHOLD, 0, &sens); +} + +static int +prism54_get_sens(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_EDTHRESHOLD, 0, NULL, &r); + + vwrq->value =3D r.u; + vwrq->disabled =3D (vwrq->value =3D=3D 0); + vwrq->fixed =3D 1; + + return rvalue; +} + +static int +prism54_get_range(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + struct iw_range *range =3D (struct iw_range *) extra; + islpci_private *priv =3D netdev_priv(ndev); + char *data; + int i, m, rvalue; + struct obj_frequencies *freq; + union oid_res_t r; + + memset(range, 0, sizeof (struct iw_range)); + dwrq->length =3D sizeof (struct iw_range); + + /* set the wireless extension version number */ + range->we_version_source =3D SUPPORTED_WIRELESS_EXT; + range->we_version_compiled =3D WIRELESS_EXT; + + /* Now the encoding capabilities */ + range->num_encoding_sizes =3D 3; + /* 64(40) bits WEP */ + range->encoding_size[0] =3D 5; + /* 128(104) bits WEP */ + range->encoding_size[1] =3D 13; + /* 256 bits for WPA-PSK */ + range->encoding_size[2] =3D 32; + /* 4 keys are allowed */ + range->max_encoding_tokens =3D 4; + + /* we don't know the quality range... */ + range->max_qual.level =3D 0; + range->max_qual.noise =3D 0; + range->max_qual.qual =3D 0; + /* these value describe an average quality. Needs more tweaking... */ + range->avg_qual.level =3D -80; /* -80 dBm */ + range->avg_qual.noise =3D 0; /* don't know what to put here */ + range->avg_qual.qual =3D 0; + + range->sensitivity =3D 200; + + /* retry limit capabilities */ + range->retry_capa =3D IW_RETRY_LIMIT | IW_RETRY_LIFETIME; + range->retry_flags =3D IW_RETRY_LIMIT; + range->r_time_flags =3D IW_RETRY_LIFETIME; + + /* I don't know the range. Put stupid things here */ + range->min_retry =3D 1; + range->max_retry =3D 65535; + range->min_r_time =3D 1024; + range->max_r_time =3D 65535 * 1024; + + /* txpower is supported in dBm's */ + range->txpower_capa =3D IW_TXPOW_DBM; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return 0; + + /* Request the device for the supported frequencies + * not really relevant since some devices will report the 5 GHz band + * frequencies even if they don't support them. + */ + rvalue =3D + mgt_get_request(priv, DOT11_OID_SUPPORTEDFREQUENCIES, 0, NULL, &r); + freq =3D r.ptr; + + range->num_channels =3D freq->nr; + range->num_frequency =3D freq->nr; + + m =3D min(IW_MAX_FREQUENCIES, (int) freq->nr); + for (i =3D 0; i < m; i++) { + range->freq[i].m =3D freq->mhz[i]; + range->freq[i].e =3D 6; + range->freq[i].i =3D channel_of_freq(freq->mhz[i]); + } + kfree(freq); + + rvalue |=3D mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r); + data =3D r.ptr; + + /* We got an array of char. It is NULL terminated. */ + i =3D 0; + while ((i < IW_MAX_BITRATES) && (*data !=3D 0)) { + /* the result must be in bps. The card gives us 500Kbps */ + range->bitrate[i] =3D (__s32) (*data >> 1); + range->bitrate[i] *=3D 1000000; + i++; + data++; + } + range->num_bitrates =3D i; + kfree(r.ptr); + + return rvalue; +} + +/* Set AP address*/ + +static int +prism54_set_wap(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + char bssid[6]; + int rvalue; + + if (awrq->sa_family !=3D ARPHRD_ETHER) + return -EINVAL; + + /* prepare the structure for the set object */ + memcpy(&bssid[0], awrq->sa_data, 6); + + /* set the bssid -- does this make sense when in AP mode? */ + rvalue =3D mgt_set_request(priv, DOT11_OID_BSSID, 0, &bssid); + + return (rvalue ? rvalue : -EINPROGRESS); /* Call commit handler */ +} + +/* get AP address*/ + +static int +prism54_get_wap(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); + memcpy(awrq->sa_data, r.ptr, 6); + awrq->sa_family =3D ARPHRD_ETHER; + kfree(r.ptr); + + return rvalue; +} + +static int +prism54_set_scan(struct net_device *dev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + /* hehe the device does this automagicaly */ + return 0; +} + +/* a little helper that will translate our data into a card independent + * format that the Wireless Tools will understand. This was inspired by + * the "Aironet driver for 4500 and 4800 series cards" (GPL) + */ + +inline char * +prism54_translate_bss(struct net_device *ndev, char *current_ev, + char *end_buf, struct obj_bss *bss, char noise) +{ + struct iw_event iwe; /* Temporary buffer */ + short cap; + islpci_private *priv =3D netdev_priv(ndev); + + /* The first entry must be the MAC address */ + memcpy(iwe.u.ap_addr.sa_data, bss->address, 6); + iwe.u.ap_addr.sa_family =3D ARPHRD_ETHER; + iwe.cmd =3D SIOCGIWAP; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_ADDR_LEN); + + /* The following entries will be displayed in the same order we give them= */ + + /* The ESSID. */ + iwe.u.data.length =3D bss->ssid.length; + iwe.u.data.flags =3D 1; + iwe.cmd =3D SIOCGIWESSID; + current_ev =3D iwe_stream_add_point(current_ev, end_buf, + &iwe, bss->ssid.octets); + + /* Capabilities */ +#define CAP_ESS 0x01 +#define CAP_IBSS 0x02 +#define CAP_CRYPT 0x10 + + /* Mode */ + cap =3D bss->capinfo; + iwe.u.mode =3D 0; + if (cap & CAP_ESS) + iwe.u.mode =3D IW_MODE_MASTER; + else if (cap & CAP_IBSS) + iwe.u.mode =3D IW_MODE_ADHOC; + iwe.cmd =3D SIOCGIWMODE; + if (iwe.u.mode) + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, + IW_EV_UINT_LEN); + + /* Encryption capability */ + if (cap & CAP_CRYPT) + iwe.u.data.flags =3D IW_ENCODE_ENABLED | IW_ENCODE_NOKEY; + else + iwe.u.data.flags =3D IW_ENCODE_DISABLED; + iwe.u.data.length =3D 0; + iwe.cmd =3D SIOCGIWENCODE; + current_ev =3D iwe_stream_add_point(current_ev, end_buf, &iwe, NULL); + + /* Add frequency. (short) bss->channel is the frequency in MHz */ + iwe.u.freq.m =3D channel_of_freq(bss->channel); + iwe.u.freq.e =3D 0; + iwe.cmd =3D SIOCGIWFREQ; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); + + /* Add quality statistics */ + iwe.u.qual.level =3D bss->rssi; + iwe.u.qual.noise =3D noise; + /* do a simple SNR for quality */ + iwe.u.qual.qual =3D bss->rssi - noise; + iwe.cmd =3D IWEVQUAL; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_QUAL_LEN); + + if (priv->wpa) { + u8 wpa_ie[MAX_WPA_IE_LEN]; + char *buf, *p; + size_t wpa_ie_len; + int i; + + wpa_ie_len =3D prism54_wpa_ie_get(priv, bss->address, wpa_ie); + if (wpa_ie_len > 0 && + (buf =3D kmalloc(wpa_ie_len * 2 + 10, GFP_ATOMIC))) { + p =3D buf; + p +=3D sprintf(p, "wpa_ie=3D"); + for (i =3D 0; i < wpa_ie_len; i++) { + p +=3D sprintf(p, "%02x", wpa_ie[i]); + } + memset(&iwe, 0, sizeof (iwe)); + iwe.cmd =3D IWEVCUSTOM; + iwe.u.data.length =3D strlen(buf); + current_ev =3D iwe_stream_add_point(current_ev, end_buf, + &iwe, buf); + kfree(buf); + } + } + return current_ev; +} + +int +prism54_get_scan(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int i, rvalue; + struct obj_bsslist *bsslist; + u32 noise =3D 0; + char *current_ev =3D extra; + union oid_res_t r; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + /* device is not ready, fail gently */ + dwrq->length =3D 0; + return 0; + } + + /* first get the noise value. We will use it to report the link quality */ + rvalue =3D mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + noise =3D r.u; + + /* Ask the device for a list of known bss. We can report at most + * IW_MAX_AP=3D64 to the range struct. But the device won't repport anyth= ing + * if you change the value of IWMAX_BSS=3D24. + */ + rvalue |=3D mgt_get_request(priv, DOT11_OID_BSSLIST, 0, NULL, &r); + bsslist =3D r.ptr; + + /* ok now, scan the list and translate its info */ + for (i =3D 0; i < min(IW_MAX_AP, (int) bsslist->nr); i++) + current_ev =3D prism54_translate_bss(ndev, current_ev, + extra + IW_SCAN_MAX_DATA, + &(bsslist->bsslist[i]), + noise); + kfree(bsslist); + dwrq->length =3D (current_ev - extra); + dwrq->flags =3D 0; /* todo */ + + return rvalue; +} + +static int +prism54_set_essid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_ssid essid; + + memset(essid.octets, 0, 33); + + /* Check if we were asked for `any' */ + if (dwrq->flags && dwrq->length) { + if (dwrq->length > min(33, IW_ESSID_MAX_SIZE + 1)) + return -E2BIG; + essid.length =3D dwrq->length - 1; + memcpy(essid.octets, extra, dwrq->length); + } else + essid.length =3D 0; + + if (priv->iw_mode !=3D IW_MODE_MONITOR) + return mgt_set_request(priv, DOT11_OID_SSID, 0, &essid); + + /* If in monitor mode, just save to mib */ + mgt_set(priv, DOT11_OID_SSID, &essid); + return 0; + +} + +static int +prism54_get_essid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_ssid *essid; + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_SSID, 0, NULL, &r); + essid =3D r.ptr; + + if (essid->length) { + dwrq->flags =3D 1; /* set ESSID to ON for Wireless Extensions */ + /* if it is to big, trunk it */ + dwrq->length =3D min(IW_ESSID_MAX_SIZE, essid->length + 1); + } else { + dwrq->flags =3D 0; + dwrq->length =3D 0; + } + essid->octets[essid->length] =3D '\0'; + memcpy(extra, essid->octets, dwrq->length); + kfree(essid); + + return rvalue; +} + +/* Provides no functionality, just completes the ioctl. In essence this is= a=20 + * just a cosmetic ioctl. + */ +static int +prism54_set_nick(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + if (dwrq->length > IW_ESSID_MAX_SIZE) + return -E2BIG; + + down_write(&priv->mib_sem); + memset(priv->nickname, 0, sizeof (priv->nickname)); + memcpy(priv->nickname, extra, dwrq->length); + up_write(&priv->mib_sem); + + return 0; +} + +static int +prism54_get_nick(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + dwrq->length =3D 0; + + down_read(&priv->mib_sem); + dwrq->length =3D strlen(priv->nickname) + 1; + memcpy(extra, priv->nickname, dwrq->length); + up_read(&priv->mib_sem); + + return 0; +} + +/* Set the allowed Bitrates */ + +static int +prism54_set_rate(struct net_device *ndev, + struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + + islpci_private *priv =3D netdev_priv(ndev); + u32 rate, profile; + char *data; + int ret, i; + union oid_res_t r; + + if (vwrq->value =3D=3D -1) { + /* auto mode. No limit. */ + profile =3D 1; + return mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); + } + + if ((ret =3D + mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r))) + return ret; + + rate =3D (u32) (vwrq->value / 500000); + data =3D r.ptr; + i =3D 0; + + while (data[i]) { + if (rate && (data[i] =3D=3D rate)) { + break; + } + if (vwrq->value =3D=3D i) { + break; + } + data[i] |=3D 0x80; + i++; + } + + if (!data[i]) { + return -EINVAL; + } + + data[i] |=3D 0x80; + data[i + 1] =3D 0; + + /* Now, check if we want a fixed or auto value */ + if (vwrq->fixed) { + data[0] =3D data[i]; + data[1] =3D 0; + } + +/* + i =3D 0; + printk("prism54 rate: "); + while(data[i]) { + printk("%u ", data[i]); + i++; + } + printk("0\n"); +*/ + profile =3D -1; + ret =3D mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); + ret |=3D mgt_set_request(priv, DOT11_OID_EXTENDEDRATES, 0, data); + ret |=3D mgt_set_request(priv, DOT11_OID_RATES, 0, data); + + kfree(r.ptr); + + return ret; +} + +/* Get the current bit rate */ +static int +prism54_get_rate(struct net_device *ndev, + struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue; + char *data; + union oid_res_t r; + + /* Get the current bit rate */ + if ((rvalue =3D mgt_get_request(priv, GEN_OID_LINKSTATE, 0, NULL, &r))) + return rvalue; + vwrq->value =3D r.u * 500000; + + /* request the device for the enabled rates */ + if ((rvalue =3D mgt_get_request(priv, DOT11_OID_RATES, 0, NULL, &r))) + return rvalue; + data =3D r.ptr; + vwrq->fixed =3D (data[0] !=3D 0) && (data[1] =3D=3D 0); + kfree(r.ptr); + + return 0; +} + +static int +prism54_set_rts(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + return mgt_set_request(priv, DOT11_OID_RTSTHRESH, 0, &vwrq->value); +} + +static int +prism54_get_rts(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + /* get the rts threshold */ + rvalue =3D mgt_get_request(priv, DOT11_OID_RTSTHRESH, 0, NULL, &r); + vwrq->value =3D r.u; + + return rvalue; +} + +static int +prism54_set_frag(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + return mgt_set_request(priv, DOT11_OID_FRAGTHRESH, 0, &vwrq->value); +} + +static int +prism54_get_frag(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_FRAGTHRESH, 0, NULL, &r); + vwrq->value =3D r.u; + + return rvalue; +} + +/* Here we have (min,max) =3D max retries for (small frames, big frames). = Where + * big frame <=3D> bigger than the rts threshold + * small frame <=3D> smaller than the rts threshold + * This is not really the behavior expected by the wireless tool but it se= ems + * to be a common behavior in other drivers. + */ + +static int +prism54_set_retry(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 slimit =3D 0, llimit =3D 0; /* short and long limit */ + u32 lifetime =3D 0; + int rvalue =3D 0; + + if (vwrq->disabled) + /* we cannot disable this feature */ + return -EINVAL; + + if (vwrq->flags & IW_RETRY_LIMIT) { + if (vwrq->flags & IW_RETRY_MIN) + slimit =3D vwrq->value; + else if (vwrq->flags & IW_RETRY_MAX) + llimit =3D vwrq->value; + else { + /* we are asked to set both */ + slimit =3D vwrq->value; + llimit =3D vwrq->value; + } + } + if (vwrq->flags & IW_RETRY_LIFETIME) + /* Wireless tools use us unit while the device uses 1024 us unit */ + lifetime =3D vwrq->value / 1024; + + /* now set what is requested */ + if (slimit) + rvalue =3D + mgt_set_request(priv, DOT11_OID_SHORTRETRIES, 0, &slimit); + if (llimit) + rvalue |=3D + mgt_set_request(priv, DOT11_OID_LONGRETRIES, 0, &llimit); + if (lifetime) + rvalue |=3D + mgt_set_request(priv, DOT11_OID_MAXTXLIFETIME, 0, + &lifetime); + return rvalue; +} + +static int +prism54_get_retry(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue =3D 0; + vwrq->disabled =3D 0; /* It cannot be disabled */ + + if ((vwrq->flags & IW_RETRY_TYPE) =3D=3D IW_RETRY_LIFETIME) { + /* we are asked for the life time */ + rvalue =3D + mgt_get_request(priv, DOT11_OID_MAXTXLIFETIME, 0, NULL, &r); + vwrq->value =3D r.u * 1024; + vwrq->flags =3D IW_RETRY_LIFETIME; + } else if ((vwrq->flags & IW_RETRY_MAX)) { + /* we are asked for the long retry limit */ + rvalue |=3D + mgt_get_request(priv, DOT11_OID_LONGRETRIES, 0, NULL, &r); + vwrq->value =3D r.u; + vwrq->flags =3D IW_RETRY_LIMIT | IW_RETRY_MAX; + } else { + /* default. get the short retry limit */ + rvalue |=3D + mgt_get_request(priv, DOT11_OID_SHORTRETRIES, 0, NULL, &r); + vwrq->value =3D r.u; + vwrq->flags =3D IW_RETRY_LIMIT | IW_RETRY_MIN; + } + + return rvalue; +} + +static int +prism54_set_encode(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue =3D 0, force =3D 0; + int authen =3D DOT11_AUTH_OS, invoke =3D 0, exunencrypt =3D 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 (dwrq->length > 0) { + /* we have a key to set */ + int index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + int current_index; + struct obj_key key =3D { DOT11_PRIV_WEP, 0, "" }; + + /* get the current key index */ + rvalue =3D mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + current_index =3D r.u; + /* Verify that the key is not marked as invalid */ + if (!(dwrq->flags & IW_ENCODE_NOKEY)) { + key.length =3D dwrq->length > sizeof (key.key) ? + sizeof (key.key) : dwrq->length; + memcpy(key.key, extra, key.length); + if (key.length =3D=3D 32) + /* we want WPA-PSK */ + key.type =3D DOT11_PRIV_TKIP; + if ((index < 0) || (index > 3)) + /* no index provided use the current one */ + index =3D current_index; + + /* now send the key to the card */ + rvalue |=3D + mgt_set_request(priv, DOT11_OID_DEFKEYX, index, + &key); + } + /* + * If a valid key is set, encryption should be enabled=20 + * (user may turn it off later). + * This is also how "iwconfig ethX key on" works + */ + if ((index =3D=3D current_index) && (key.length > 0)) + force =3D 1; + } else { + int index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + if ((index >=3D 0) && (index <=3D 3)) { + /* we want to set the key index */ + rvalue |=3D + mgt_set_request(priv, DOT11_OID_DEFKEYID, 0, + &index); + } else { + if (!dwrq->flags & IW_ENCODE_MODE) { + /* we cannot do anything. Complain. */ + return -EINVAL; + } + } + } + /* now read the flags */ + if (dwrq->flags & IW_ENCODE_DISABLED) { + /* Encoding disabled,=20 + * authen =3D DOT11_AUTH_OS; + * invoke =3D 0; + * exunencrypt =3D 0; */ + } + if (dwrq->flags & IW_ENCODE_OPEN) + /* Encode but accept non-encoded packets. No auth */ + invoke =3D 1; + if ((dwrq->flags & IW_ENCODE_RESTRICTED) || force) { + /* Refuse non-encoded packets. Auth */ + authen =3D DOT11_AUTH_BOTH; + invoke =3D 1; + exunencrypt =3D 1; + } + /* do the change if requested */ + if ((dwrq->flags & IW_ENCODE_MODE) || force) { + rvalue |=3D + mgt_set_request(priv, DOT11_OID_AUTHENABLE, 0, &authen); + rvalue |=3D + mgt_set_request(priv, DOT11_OID_PRIVACYINVOKED, 0, &invoke); + rvalue |=3D + mgt_set_request(priv, DOT11_OID_EXUNENCRYPTED, 0, + &exunencrypt); + } + return rvalue; +} + +static int +prism54_get_encode(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_key *key; + u32 devindex, index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + u32 authen =3D 0, invoke =3D 0, exunencrypt =3D 0; + int rvalue; + union oid_res_t r; + + /* first get the flags */ + rvalue =3D mgt_get_request(priv, DOT11_OID_AUTHENABLE, 0, NULL, &r); + authen =3D r.u; + rvalue |=3D mgt_get_request(priv, DOT11_OID_PRIVACYINVOKED, 0, NULL, &r); + invoke =3D r.u; + rvalue |=3D mgt_get_request(priv, DOT11_OID_EXUNENCRYPTED, 0, NULL, &r); + exunencrypt =3D r.u; + + if (invoke && (authen =3D=3D DOT11_AUTH_BOTH) && exunencrypt) + dwrq->flags =3D IW_ENCODE_RESTRICTED; + else if ((authen =3D=3D DOT11_AUTH_OS) && !exunencrypt) { + if (invoke) + dwrq->flags =3D IW_ENCODE_OPEN; + else + dwrq->flags =3D IW_ENCODE_DISABLED; + } else + /* The card should not work in this state */ + dwrq->flags =3D 0; + + /* get the current device key index */ + rvalue |=3D mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + devindex =3D r.u; + /* Now get the key, return it */ + if ((index < 0) || (index > 3)) + /* no index provided, use the current one */ + index =3D devindex; + rvalue |=3D mgt_get_request(priv, DOT11_OID_DEFKEYX, index, NULL, &r); + key =3D r.ptr; + dwrq->length =3D key->length; + memcpy(extra, key->key, dwrq->length); + kfree(key); + /* return the used key index */ + dwrq->flags |=3D devindex + 1; + + return rvalue; +} + +static int +prism54_get_txpower(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, OID_INL_OUTPUTPOWER, 0, NULL, &r); + /* intersil firmware operates in 0.25 dBm (1/4 dBm) */ + vwrq->value =3D (s32) r.u / 4; + vwrq->fixed =3D 1; + /* radio is not turned of + * btw: how is possible to turn off only the radio=20 + */ + vwrq->disabled =3D 0; + + return rvalue; +} + +static int +prism54_set_txpower(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + s32 u =3D vwrq->value; + + /* intersil firmware operates in 0.25 dBm (1/4) */ + u *=3D 4; + if (vwrq->disabled) { + /* don't know how to disable radio */ + printk(KERN_DEBUG + "%s: %s() disabling radio is not yet supported.\n", + priv->ndev->name, __FUNCTION__); + return -ENOTSUPP; + } else if (vwrq->fixed) + /* currently only fixed value is supported */ + return mgt_set_request(priv, OID_INL_OUTPUTPOWER, 0, &u); + else { + printk(KERN_DEBUG + "%s: %s() auto power will be implemented later.\n", + priv->ndev->name, __FUNCTION__); + return -ENOTSUPP; + } +} + +static int +prism54_reset(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_reset(netdev_priv(ndev), 0); + + return 0; +} + +static int +prism54_get_oid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + union oid_res_t r; + int rvalue; + enum oid_num_t n =3D dwrq->flags; + + rvalue =3D mgt_get_request((islpci_private *) ndev->priv, n, 0, NULL, &r); + dwrq->length =3D mgt_response_to_str(n, &r, extra); + if ((isl_oid[n].flags & OID_FLAG_TYPE) !=3D OID_TYPE_U32) + kfree(r.ptr); + return rvalue; +} + +static int +prism54_set_u32(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + u32 oid =3D uwrq[0], u =3D uwrq[1]; + + return mgt_set_request((islpci_private *) ndev->priv, oid, 0, &u); +} + +static int +prism54_set_raw(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + u32 oid =3D dwrq->flags; + + return mgt_set_request((islpci_private *) ndev->priv, oid, 0, extra); +} + +void +prism54_acl_init(struct islpci_acl *acl) +{ + sema_init(&acl->sem, 1); + INIT_LIST_HEAD(&acl->mac_list); + acl->size =3D 0; + acl->policy =3D MAC_POLICY_OPEN; +} + +static void +prism54_clear_mac(struct islpci_acl *acl) +{ + struct list_head *ptr, *next; + struct mac_entry *entry; + + if (down_interruptible(&acl->sem)) + return; + + if (acl->size =3D=3D 0) { + up(&acl->sem); + return; + } + + for (ptr =3D acl->mac_list.next, next =3D ptr->next; + ptr !=3D &acl->mac_list; ptr =3D next, next =3D ptr->next) { + entry =3D list_entry(ptr, struct mac_entry, _list); + list_del(ptr); + kfree(entry); + } + acl->size =3D 0; + up(&acl->sem); +} + +void +prism54_acl_clean(struct islpci_acl *acl) +{ + prism54_clear_mac(acl); +} + +static int +prism54_add_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct sockaddr *addr =3D (struct sockaddr *) extra; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + entry =3D kmalloc(sizeof (struct mac_entry), GFP_KERNEL); + if (entry =3D=3D NULL) + return -ENOMEM; + + memcpy(entry->addr, addr->sa_data, ETH_ALEN); + + if (down_interruptible(&acl->sem)) { + kfree(entry); + return -ERESTARTSYS; + } + list_add_tail(&entry->_list, &acl->mac_list); + acl->size++; + up(&acl->sem); + + return 0; +} + +static int +prism54_del_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct list_head *ptr; + struct sockaddr *addr =3D (struct sockaddr *) extra; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + + if (memcmp(entry->addr, addr->sa_data, ETH_ALEN) =3D=3D 0) { + list_del(ptr); + acl->size--; + kfree(entry); + up(&acl->sem); + return 0; + } + } + up(&acl->sem); + return -EINVAL; +} + +static int +prism54_get_mac(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct list_head *ptr; + struct sockaddr *dst =3D (struct sockaddr *) extra; + + dwrq->length =3D 0; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + + memcpy(dst->sa_data, entry->addr, ETH_ALEN); + dst->sa_family =3D ARPHRD_ETHER; + dwrq->length++; + dst++; + } + up(&acl->sem); + return 0; +} + +/* Setting policy also clears the MAC acl, even if we don't change the def= aut + * policy + */ + +static int +prism54_set_policy(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + u32 mlmeautolevel; + + prism54_clear_mac(acl); + + if ((*uwrq < MAC_POLICY_OPEN) || (*uwrq > MAC_POLICY_REJECT)) + return -EINVAL; + + down_write(&priv->mib_sem); + + acl->policy =3D *uwrq; + + /* the ACL code needs an intermediate mlmeautolevel */ + if ((priv->iw_mode =3D=3D IW_MODE_MASTER) && + (acl->policy !=3D MAC_POLICY_OPEN)) + mlmeautolevel =3D DOT11_MLME_INTERMEDIATE; + else + mlmeautolevel =3D CARD_DEFAULT_MLME_MODE; + if (priv->wpa) + mlmeautolevel =3D DOT11_MLME_EXTENDED; + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlmeautolevel); + /* restart the card with our new policy */ + mgt_commit(priv); + up_write(&priv->mib_sem); + + return 0; +} + +static int +prism54_get_policy(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + + *uwrq =3D acl->policy; + + return 0; +} + +/* Return 1 only if client should be accepted. */ + +static int +prism54_mac_accept(struct islpci_acl *acl, char *mac) +{ + struct list_head *ptr; + struct mac_entry *entry; + int res =3D 0; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + + if (acl->policy =3D=3D MAC_POLICY_OPEN) { + up(&acl->sem); + return 1; + } + + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + if (memcmp(entry->addr, mac, ETH_ALEN) =3D=3D 0) { + res =3D 1; + break; + } + } + res =3D (acl->policy =3D=3D MAC_POLICY_ACCEPT) ? !res : res; + up(&acl->sem); + + return res; +} + +static int +prism54_kick_all(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + struct obj_mlme *mlme; + int rvalue; + + mlme =3D kmalloc(sizeof (struct obj_mlme), GFP_KERNEL); + if (mlme =3D=3D NULL) + return -ENOMEM; + + /* Tell the card to kick every client */ + mlme->id =3D 0; + rvalue =3D + mgt_set_request(netdev_priv(ndev), DOT11_OID_DISASSOCIATE, 0, mlme); + kfree(mlme); + + return rvalue; +} + +static int +prism54_kick_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + struct obj_mlme *mlme; + struct sockaddr *addr =3D (struct sockaddr *) extra; + int rvalue; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + mlme =3D kmalloc(sizeof (struct obj_mlme), GFP_KERNEL); + if (mlme =3D=3D NULL) + return -ENOMEM; + + /* Tell the card to only kick the corresponding bastard */ + memcpy(mlme->address, addr->sa_data, ETH_ALEN); + mlme->id =3D -1; + rvalue =3D + mgt_set_request(netdev_priv(ndev), DOT11_OID_DISASSOCIATE, 0, mlme); + + kfree(mlme); + + return rvalue; +} + +/* Translate a TRAP oid into a wireless event. Called in islpci_mgt_receiv= e. */ + +static inline void +format_event(islpci_private *priv, char *dest, const char *str, + const struct obj_mlme *mlme, u16 *length, int error) +{ + const u8 *a =3D mlme->address; + int n =3D snprintf(dest, IW_CUSTOM_MAX, + "%s %s %2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X %s (%2.2X)", + str, + ((priv->iw_mode =3D=3D IW_MODE_MASTER) ? "from" : "to"), + a[0], a[1], a[2], a[3], a[4], a[5], + (error ? (mlme->code ? " : REJECTED " : " : ACCEPTED ") + : ""), mlme->code); + BUG_ON(n > IW_CUSTOM_MAX); + *length =3D n; +} + +static void +send_formatted_event(islpci_private *priv, const char *str, + const struct obj_mlme *mlme, int error) +{ + union iwreq_data wrqu; + + wrqu.data.pointer =3D kmalloc(IW_CUSTOM_MAX, GFP_KERNEL); + if (!wrqu.data.pointer) + return; + wrqu.data.length =3D 0; + format_event(priv, wrqu.data.pointer, str, mlme, &wrqu.data.length, + error); + wireless_send_event(priv->ndev, IWEVCUSTOM, &wrqu, wrqu.data.pointer); + kfree(wrqu.data.pointer); +} + +static void +send_simple_event(islpci_private *priv, const char *str) +{ + union iwreq_data wrqu; + int n =3D strlen(str); + + wrqu.data.pointer =3D kmalloc(IW_CUSTOM_MAX, GFP_KERNEL); + if (!wrqu.data.pointer) + return; + BUG_ON(n > IW_CUSTOM_MAX); + wrqu.data.length =3D n; + strcpy(wrqu.data.pointer, str); + wireless_send_event(priv->ndev, IWEVCUSTOM, &wrqu, wrqu.data.pointer); + kfree(wrqu.data.pointer); +} + +static void +link_changed(struct net_device *ndev, u32 bitrate) +{ + islpci_private *priv =3D netdev_priv(ndev); + + if (bitrate) { + if (priv->iw_mode =3D=3D IW_MODE_INFRA) { + union iwreq_data uwrq; + prism54_get_wap(ndev, NULL, (struct sockaddr *) &uwrq, + NULL); + wireless_send_event(ndev, SIOCGIWAP, &uwrq, NULL); + } else + send_simple_event(netdev_priv(ndev), + "Link established"); + } else + send_simple_event(netdev_priv(ndev), "Link lost"); +} + +/* Beacon/ProbeResp payload header */ +struct ieee80211_beacon_phdr { + u8 timestamp[8]; + u16 beacon_int; + u16 capab_info; +} __attribute__ ((packed)); + +#define WLAN_EID_GENERIC 0xdd +static u8 wpa_oid[4] =3D { 0x00, 0x50, 0xf2, 1 }; + +#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5] +#define MACSTR "%02x:%02x:%02x:%02x:%02x:%02x" + +void +prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len) +{ + struct list_head *ptr; + struct islpci_bss_wpa_ie *bss =3D NULL; + + if (wpa_ie_len > MAX_WPA_IE_LEN) + wpa_ie_len =3D MAX_WPA_IE_LEN; + + if (down_interruptible(&priv->wpa_sem)) + return; + + /* try to use existing entry */ + list_for_each(ptr, &priv->bss_wpa_list) { + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + if (memcmp(bss->bssid, bssid, ETH_ALEN) =3D=3D 0) { + list_move(&bss->list, &priv->bss_wpa_list); + break; + } + bss =3D NULL; + } + + if (bss =3D=3D NULL) { + /* add a new BSS entry; if max number of entries is already + * reached, replace the least recently updated */ + if (priv->num_bss_wpa >=3D MAX_BSS_WPA_IE_COUNT) { + bss =3D list_entry(priv->bss_wpa_list.prev, + struct islpci_bss_wpa_ie, list); + list_del(&bss->list); + } else { + bss =3D kmalloc(sizeof (*bss), GFP_ATOMIC); + if (bss !=3D NULL) { + priv->num_bss_wpa++; + memset(bss, 0, sizeof (*bss)); + } + } + if (bss !=3D NULL) { + memcpy(bss->bssid, bssid, ETH_ALEN); + list_add(&bss->list, &priv->bss_wpa_list); + } + } + + if (bss !=3D NULL) { + memcpy(bss->wpa_ie, wpa_ie, wpa_ie_len); + bss->wpa_ie_len =3D wpa_ie_len; + bss->last_update =3D jiffies; + } else { + printk(KERN_DEBUG "Failed to add BSS WPA entry for " MACSTR + "\n", MAC2STR(bssid)); + } + + /* expire old entries from WPA list */ + while (priv->num_bss_wpa > 0) { + bss =3D list_entry(priv->bss_wpa_list.prev, + struct islpci_bss_wpa_ie, list); + if (!time_after(jiffies, bss->last_update + 60 * HZ)) + break; + + list_del(&bss->list); + priv->num_bss_wpa--; + kfree(bss); + } + + up(&priv->wpa_sem); +} + +size_t +prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie) +{ + struct list_head *ptr; + struct islpci_bss_wpa_ie *bss =3D NULL; + size_t len =3D 0; + + if (down_interruptible(&priv->wpa_sem)) + return 0; + + list_for_each(ptr, &priv->bss_wpa_list) { + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + if (memcmp(bss->bssid, bssid, ETH_ALEN) =3D=3D 0) + break; + bss =3D NULL; + } + if (bss) { + len =3D bss->wpa_ie_len; + memcpy(wpa_ie, bss->wpa_ie, len); + } + up(&priv->wpa_sem); + + return len; +} + +void +prism54_wpa_ie_init(islpci_private *priv) +{ + INIT_LIST_HEAD(&priv->bss_wpa_list); + sema_init(&priv->wpa_sem, 1); +} + +void +prism54_wpa_ie_clean(islpci_private *priv) +{ + struct list_head *ptr, *n; + + list_for_each_safe(ptr, n, &priv->bss_wpa_list) { + struct islpci_bss_wpa_ie *bss; + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + kfree(bss); + } +} + +static void +prism54_process_bss_data(islpci_private *priv, u32 oid, u8 *addr, + u8 *payload, size_t len) +{ + struct ieee80211_beacon_phdr *hdr; + u8 *pos, *end; + + if (!priv->wpa) + return; + + hdr =3D (struct ieee80211_beacon_phdr *) payload; + pos =3D (u8 *) (hdr + 1); + end =3D payload + len; + while (pos < end) { + if (pos + 2 + pos[1] > end) { + printk(KERN_DEBUG "Parsing Beacon/ProbeResp failed " + "for " MACSTR "\n", MAC2STR(addr)); + return; + } + if (pos[0] =3D=3D WLAN_EID_GENERIC && pos[1] >=3D 4 && + memcmp(pos + 2, wpa_oid, 4) =3D=3D 0) { + prism54_wpa_ie_add(priv, addr, pos, pos[1] + 2); + return; + } + pos +=3D 2 + pos[1]; + } +} + +static void +handle_request(islpci_private *priv, struct obj_mlme *mlme, enum oid_num_t= oid) +{ + if (((mlme->state =3D=3D DOT11_STATE_AUTHING) || + (mlme->state =3D=3D DOT11_STATE_ASSOCING)) + && mgt_mlme_answer(priv)) { + /* Someone is requesting auth and we must respond. Just send back + * the trap with error code set accordingly. + */ + mlme->code =3D prism54_mac_accept(&priv->acl, + mlme->address) ? 0 : 1; + mgt_set_request(priv, oid, 0, mlme); + } +} + +int +prism54_process_trap_helper(islpci_private *priv, enum oid_num_t oid, + char *data) +{ + struct obj_mlme *mlme =3D (struct obj_mlme *) data; + size_t len; + u8 *payload, *pos =3D (u8 *) (mlme + 1); + + len =3D pos[0] | (pos[1] << 8); /* little endian data length */ + payload =3D pos + 2; + + /* I think all trapable objects are listed here. + * Some oids have a EX version. The difference is that they are emitted + * in DOT11_MLME_EXTENDED mode (set with DOT11_OID_MLMEAUTOLEVEL) + * with more info. + * The few events already defined by the wireless tools are not really + * suited. We use the more flexible custom event facility. + */ + + /* I fear prism54_process_bss_data won't work with big endian data */ + if ((oid =3D=3D DOT11_OID_BEACON) || (oid =3D=3D DOT11_OID_PROBE)) + prism54_process_bss_data(priv, oid, mlme->address, + payload, len); + + mgt_le_to_cpu(isl_oid[oid].flags & OID_FLAG_TYPE, (void *) mlme); + + switch (oid) { + + case GEN_OID_LINKSTATE: + link_changed(priv->ndev, (u32) *data); + break; + + case DOT11_OID_MICFAILURE: + send_simple_event(priv, "Mic failure"); + break; + + case DOT11_OID_DEAUTHENTICATE: + send_formatted_event(priv, "DeAuthenticate request", mlme, 0); + break; + + case DOT11_OID_AUTHENTICATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Authenticate request", mlme, 1); + break; + + case DOT11_OID_DISASSOCIATE: + send_formatted_event(priv, "Disassociate request", mlme, 0); + break; + + case DOT11_OID_ASSOCIATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Associate request", mlme, 1); + break; + + case DOT11_OID_REASSOCIATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "ReAssociate request", mlme, 1); + break; + + case DOT11_OID_BEACON: + send_formatted_event(priv, + "Received a beacon from an unkown AP", + mlme, 0); + break; + + case DOT11_OID_PROBE: + /* we received a probe from a client. */ + send_formatted_event(priv, "Received a probe from client", mlme, + 0); + break; + + /* Note : "mlme" is actually a "struct obj_mlmeex *" here, but this + * is backward compatible layout-wise with "struct obj_mlme". + */ + + case DOT11_OID_DEAUTHENTICATEEX: + send_formatted_event(priv, "DeAuthenticate request", mlme, 0); + break; + + case DOT11_OID_AUTHENTICATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Authenticate request", mlme, 1); + break; + + case DOT11_OID_DISASSOCIATEEX: + send_formatted_event(priv, "Disassociate request", mlme, 0); + break; + + case DOT11_OID_ASSOCIATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Associate request", mlme, 1); + break; + + case DOT11_OID_REASSOCIATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Reassociate request", mlme, 1); + break; + + default: + return -EINVAL; + } + + return 0; +} + +/* + * Process a device trap. This is called via schedule_work(), outside of + * interrupt context, no locks held. + */ +void +prism54_process_trap(void *data) +{ + struct islpci_mgmtframe *frame =3D data; + struct net_device *ndev =3D frame->ndev; + enum oid_num_t n =3D mgt_oidtonum(frame->header->oid); + + if (n !=3D OID_NUM_LAST) + prism54_process_trap_helper(netdev_priv(ndev), n, frame->data); + islpci_mgt_release(frame); +} + +int +prism54_set_mac_address(struct net_device *ndev, void *addr) +{ + islpci_private *priv =3D netdev_priv(ndev); + int ret; + + if (ndev->addr_len !=3D 6) + return -EINVAL; + ret =3D mgt_set_request(priv, GEN_OID_MACADDRESS, 0, + &((struct sockaddr *) addr)->sa_data); + if (!ret) + memcpy(priv->ndev->dev_addr, + &((struct sockaddr *) addr)->sa_data, 6); + + return ret; +} + +int +prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + down_write(&priv->mib_sem); + + priv->wpa =3D *uwrq; + if (priv->wpa) { + u32 l =3D DOT11_MLME_EXTENDED; + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &l); + } + /* restart the card with new level. Needed ? */ + mgt_commit(priv); + up_write(&priv->mib_sem); + + return 0; +} + +int +prism54_get_wpa(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + *uwrq =3D priv->wpa; + return 0; +} + +int +prism54_set_prismhdr(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + priv->monitor_type =3D + (*uwrq ? ARPHRD_IEEE80211_PRISM : ARPHRD_IEEE80211); + if (priv->iw_mode =3D=3D IW_MODE_MONITOR) + priv->ndev->type =3D priv->monitor_type; + + return 0; +} + +int +prism54_get_prismhdr(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + *uwrq =3D (priv->monitor_type =3D=3D ARPHRD_IEEE80211_PRISM); + return 0; +} + +int +prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + priv->priv_oid =3D *uwrq; + printk("%s: oid 0x%08X\n", ndev->name, *uwrq); + + return 0; +} + +int +prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *inf= o, + struct iw_point *data, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_mgmtframe *response =3D NULL; + int ret =3D -EIO, response_op =3D PIMFOR_OP_ERROR; + + printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); + data->length =3D 0; + + if (islpci_get_state(priv) >=3D PRV_STATE_INIT) { + ret =3D + islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + priv->priv_oid, extra, 256, + &response); + response_op =3D 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 =3D=3D PIMFOR_OP_ERROR) { + if (response) { + islpci_mgt_release(response); + } + printk("%s: EIO\n", ndev->name); + ret =3D -EIO; + } + if (!ret) { + data->length =3D response->header->length; + memcpy(extra, response->data, data->length); + islpci_mgt_release(response); + printk("%s: len: %i\n", ndev->name, data->length); + } + } + + return ret; +} + +int +prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *inf= o, + struct iw_point *data, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_mgmtframe *response =3D NULL; + int ret =3D 0, response_op =3D PIMFOR_OP_ERROR; + + printk("%s: set_oid 0x%08X\tlen: %d\n", ndev->name, priv->priv_oid, + data->length); + + if (islpci_get_state(priv) >=3D PRV_STATE_INIT) { + ret =3D + islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + priv->priv_oid, extra, data->length, + &response); + printk("%s: ret: %i\n", ndev->name, ret); + if (!ret) { + response_op =3D response->header->operation; + printk("%s: response_op: %i\n", ndev->name, + response_op); + islpci_mgt_release(response); + } + if (ret || response_op =3D=3D PIMFOR_OP_ERROR) { + printk("%s: EIO\n", ndev->name); + ret =3D -EIO; + } + } + + return (ret ? ret : -EINPROGRESS); +} + +static int +prism54_set_spy(struct net_device *ndev, + struct iw_request_info *info, + union iwreq_data *uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 u, oid =3D OID_INL_CONFIG; + + down_write(&priv->mib_sem); + mgt_get(priv, OID_INL_CONFIG, &u); + + if ((uwrq->data.length =3D=3D 0) && (priv->spy_data.spy_number > 0)) + /* disable spy */ + u &=3D ~INL_CONFIG_RXANNEX; + else if ((uwrq->data.length > 0) && (priv->spy_data.spy_number =3D=3D 0)) + /* enable spy */ + u |=3D INL_CONFIG_RXANNEX; + + mgt_set(priv, OID_INL_CONFIG, &u); + mgt_commit_list(priv, &oid, 1); + up_write(&priv->mib_sem); + + return iw_handler_set_spy(ndev, info, uwrq, extra); +} + +static const iw_handler prism54_handler[] =3D { + (iw_handler) prism54_commit, /* SIOCSIWCOMMIT */ + (iw_handler) prism54_get_name, /* SIOCGIWNAME */ + (iw_handler) NULL, /* SIOCSIWNWID */ + (iw_handler) NULL, /* SIOCGIWNWID */ + (iw_handler) prism54_set_freq, /* SIOCSIWFREQ */ + (iw_handler) prism54_get_freq, /* SIOCGIWFREQ */ + (iw_handler) prism54_set_mode, /* SIOCSIWMODE */ + (iw_handler) prism54_get_mode, /* SIOCGIWMODE */ + (iw_handler) prism54_set_sens, /* SIOCSIWSENS */ + (iw_handler) prism54_get_sens, /* SIOCGIWSENS */ + (iw_handler) NULL, /* SIOCSIWRANGE */ + (iw_handler) prism54_get_range, /* SIOCGIWRANGE */ + (iw_handler) NULL, /* SIOCSIWPRIV */ + (iw_handler) NULL, /* SIOCGIWPRIV */ + (iw_handler) NULL, /* SIOCSIWSTATS */ + (iw_handler) NULL, /* SIOCGIWSTATS */ + prism54_set_spy, /* SIOCSIWSPY */ + iw_handler_get_spy, /* SIOCGIWSPY */ + iw_handler_set_thrspy, /* SIOCSIWTHRSPY */ + iw_handler_get_thrspy, /* SIOCGIWTHRSPY */ + (iw_handler) prism54_set_wap, /* SIOCSIWAP */ + (iw_handler) prism54_get_wap, /* SIOCGIWAP */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* SIOCGIWAPLIST depreciated */ + (iw_handler) prism54_set_scan, /* SIOCSIWSCAN */ + (iw_handler) prism54_get_scan, /* SIOCGIWSCAN */ + (iw_handler) prism54_set_essid, /* SIOCSIWESSID */ + (iw_handler) prism54_get_essid, /* SIOCGIWESSID */ + (iw_handler) prism54_set_nick, /* SIOCSIWNICKN */ + (iw_handler) prism54_get_nick, /* SIOCGIWNICKN */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) prism54_set_rate, /* SIOCSIWRATE */ + (iw_handler) prism54_get_rate, /* SIOCGIWRATE */ + (iw_handler) prism54_set_rts, /* SIOCSIWRTS */ + (iw_handler) prism54_get_rts, /* SIOCGIWRTS */ + (iw_handler) prism54_set_frag, /* SIOCSIWFRAG */ + (iw_handler) prism54_get_frag, /* SIOCGIWFRAG */ + (iw_handler) prism54_set_txpower, /* SIOCSIWTXPOW */ + (iw_handler) prism54_get_txpower, /* SIOCGIWTXPOW */ + (iw_handler) prism54_set_retry, /* SIOCSIWRETRY */ + (iw_handler) prism54_get_retry, /* SIOCGIWRETRY */ + (iw_handler) prism54_set_encode, /* SIOCSIWENCODE */ + (iw_handler) prism54_get_encode, /* SIOCGIWENCODE */ + (iw_handler) NULL, /* SIOCSIWPOWER */ + (iw_handler) NULL, /* SIOCGIWPOWER */ +}; + +/* The low order bit identify a SET (0) or a GET (1) ioctl. */ + +#define PRISM54_RESET SIOCIWFIRSTPRIV +#define PRISM54_GET_POLICY SIOCIWFIRSTPRIV+1 +#define PRISM54_SET_POLICY SIOCIWFIRSTPRIV+2 +#define PRISM54_GET_MAC SIOCIWFIRSTPRIV+3 +#define PRISM54_ADD_MAC SIOCIWFIRSTPRIV+4 + +#define PRISM54_DEL_MAC SIOCIWFIRSTPRIV+6 + +#define PRISM54_KICK_MAC SIOCIWFIRSTPRIV+8 + +#define PRISM54_KICK_ALL SIOCIWFIRSTPRIV+10 + +#define PRISM54_GET_WPA SIOCIWFIRSTPRIV+11 +#define PRISM54_SET_WPA SIOCIWFIRSTPRIV+12 + +#define PRISM54_DBG_OID SIOCIWFIRSTPRIV+14 +#define PRISM54_DBG_GET_OID SIOCIWFIRSTPRIV+15 +#define PRISM54_DBG_SET_OID SIOCIWFIRSTPRIV+16 + +#define PRISM54_GET_OID SIOCIWFIRSTPRIV+17 +#define PRISM54_SET_OID_U32 SIOCIWFIRSTPRIV+18 +#define PRISM54_SET_OID_STR SIOCIWFIRSTPRIV+20 +#define PRISM54_SET_OID_ADDR SIOCIWFIRSTPRIV+22 + +#define PRISM54_GET_PRISMHDR SIOCIWFIRSTPRIV+23 +#define PRISM54_SET_PRISMHDR SIOCIWFIRSTPRIV+24 + +#define IWPRIV_SET_U32(n,x) { n, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1= , 0, "s_"x } +#define IWPRIV_SET_SSID(n,x) { n, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED |= 1, 0, "s_"x } +#define IWPRIV_SET_ADDR(n,x) { n, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED |= 1, 0, "s_"x } +#define IWPRIV_GET(n,x) { n, 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | P= RIV_STR_SIZE, "g_"x } + +#define IWPRIV_U32(n,x) IWPRIV_SET_U32(n,x), IWPRIV_GET(n,x) +#define IWPRIV_SSID(n,x) IWPRIV_SET_SSID(n,x), IWPRIV_GET(n,x) +#define IWPRIV_ADDR(n,x) IWPRIV_SET_ADDR(n,x), IWPRIV_GET(n,x) + +/* Note : limited to 128 private ioctls (wireless tools 26) */ + +static const struct iw_priv_args prism54_private_args[] =3D { +/*{ cmd, set_args, get_args, name } */ + {PRISM54_RESET, 0, 0, "reset"}, + {PRISM54_GET_PRISMHDR, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "get_prismhdr"}, + {PRISM54_SET_PRISMHDR, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "set_prismhdr"}, + {PRISM54_GET_POLICY, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "getPolicy"}, + {PRISM54_SET_POLICY, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "setPolicy"}, + {PRISM54_GET_MAC, 0, IW_PRIV_TYPE_ADDR | 64, "getMac"}, + {PRISM54_ADD_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "addMac"}, + {PRISM54_DEL_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "delMac"}, + {PRISM54_KICK_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "kickMac"}, + {PRISM54_KICK_ALL, 0, 0, "kickAll"}, + {PRISM54_GET_WPA, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "get_wpa"}, + {PRISM54_SET_WPA, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "set_wpa"}, + {PRISM54_DBG_OID, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "dbg_oid"}, + {PRISM54_DBG_GET_OID, 0, IW_PRIV_TYPE_BYTE | 256, "dbg_get_oid"}, + {PRISM54_DBG_SET_OID, IW_PRIV_TYPE_BYTE | 256, 0, "dbg_set_oid"}, + /* --- sub-ioctls handlers --- */ + {PRISM54_GET_OID, + 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | PRIV_STR_SIZE, ""}, + {PRISM54_SET_OID_U32, + IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + {PRISM54_SET_OID_STR, + IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + {PRISM54_SET_OID_ADDR, + IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + /* --- sub-ioctls definitions --- */ + IWPRIV_ADDR(GEN_OID_MACADDRESS, "addr"), + IWPRIV_GET(GEN_OID_LINKSTATE, "linkstate"), + IWPRIV_U32(DOT11_OID_BSSTYPE, "bsstype"), + IWPRIV_ADDR(DOT11_OID_BSSID, "bssid"), + IWPRIV_U32(DOT11_OID_STATE, "state"), + IWPRIV_U32(DOT11_OID_AID, "aid"), + + IWPRIV_SSID(DOT11_OID_SSIDOVERRIDE, "ssidoverride"), + + IWPRIV_U32(DOT11_OID_MEDIUMLIMIT, "medlimit"), + IWPRIV_U32(DOT11_OID_BEACONPERIOD, "beacon"), + IWPRIV_U32(DOT11_OID_DTIMPERIOD, "dtimperiod"), + + IWPRIV_U32(DOT11_OID_AUTHENABLE, "authenable"), + IWPRIV_U32(DOT11_OID_PRIVACYINVOKED, "privinvok"), + IWPRIV_U32(DOT11_OID_EXUNENCRYPTED, "exunencrypt"), + + IWPRIV_U32(DOT11_OID_REKEYTHRESHOLD, "rekeythresh"), + + IWPRIV_U32(DOT11_OID_MAXTXLIFETIME, "maxtxlife"), + IWPRIV_U32(DOT11_OID_MAXRXLIFETIME, "maxrxlife"), + IWPRIV_U32(DOT11_OID_ALOFT_FIXEDRATE, "fixedrate"), + IWPRIV_U32(DOT11_OID_MAXFRAMEBURST, "frameburst"), + IWPRIV_U32(DOT11_OID_PSM, "psm"), + + IWPRIV_U32(DOT11_OID_BRIDGELOCAL, "bridge"), + IWPRIV_U32(DOT11_OID_CLIENTS, "clients"), + IWPRIV_U32(DOT11_OID_CLIENTSASSOCIATED, "clientassoc"), + IWPRIV_U32(DOT11_OID_DOT1XENABLE, "dot1xenable"), + IWPRIV_U32(DOT11_OID_ANTENNARX, "rxant"), + IWPRIV_U32(DOT11_OID_ANTENNATX, "txant"), + IWPRIV_U32(DOT11_OID_ANTENNADIVERSITY, "antdivers"), + IWPRIV_U32(DOT11_OID_EDTHRESHOLD, "edthresh"), + IWPRIV_U32(DOT11_OID_PREAMBLESETTINGS, "preamble"), + IWPRIV_GET(DOT11_OID_RATES, "rates"), + IWPRIV_U32(DOT11_OID_OUTPUTPOWER, ".11outpower"), + IWPRIV_GET(DOT11_OID_SUPPORTEDRATES, "supprates"), + IWPRIV_GET(DOT11_OID_SUPPORTEDFREQUENCIES, "suppfreq"), + + IWPRIV_U32(DOT11_OID_NOISEFLOOR, "noisefloor"), + IWPRIV_GET(DOT11_OID_FREQUENCYACTIVITY, "freqactivity"), + IWPRIV_U32(DOT11_OID_NONERPPROTECTION, "nonerpprotec"), + IWPRIV_U32(DOT11_OID_PROFILES, "profile"), + IWPRIV_GET(DOT11_OID_EXTENDEDRATES, "extrates"), + IWPRIV_U32(DOT11_OID_MLMEAUTOLEVEL, "mlmelevel"), + + IWPRIV_GET(DOT11_OID_BSSS, "bsss"), + IWPRIV_GET(DOT11_OID_BSSLIST, "bsslist"), + IWPRIV_U32(OID_INL_MODE, "mode"), + IWPRIV_U32(OID_INL_CONFIG, "config"), + IWPRIV_U32(OID_INL_DOT11D_CONFORMANCE, ".11dconform"), + IWPRIV_GET(OID_INL_PHYCAPABILITIES, "phycapa"), + IWPRIV_U32(OID_INL_OUTPUTPOWER, "outpower"), +}; + +static const iw_handler prism54_private_handler[] =3D { + (iw_handler) prism54_reset, + (iw_handler) prism54_get_policy, + (iw_handler) prism54_set_policy, + (iw_handler) prism54_get_mac, + (iw_handler) prism54_add_mac, + (iw_handler) NULL, + (iw_handler) prism54_del_mac, + (iw_handler) NULL, + (iw_handler) prism54_kick_mac, + (iw_handler) NULL, + (iw_handler) prism54_kick_all, + (iw_handler) prism54_get_wpa, + (iw_handler) prism54_set_wpa, + (iw_handler) NULL, + (iw_handler) prism54_debug_oid, + (iw_handler) prism54_debug_get_oid, + (iw_handler) prism54_debug_set_oid, + (iw_handler) prism54_get_oid, + (iw_handler) prism54_set_u32, + (iw_handler) NULL, + (iw_handler) prism54_set_raw, + (iw_handler) NULL, + (iw_handler) prism54_set_raw, + (iw_handler) prism54_get_prismhdr, + (iw_handler) prism54_set_prismhdr, +}; + +const struct iw_handler_def prism54_handler_def =3D { + .num_standard =3D sizeof (prism54_handler) / sizeof (iw_handler), + .num_private =3D sizeof (prism54_private_handler) / sizeof (iw_handler), + .num_private_args =3D + sizeof (prism54_private_args) / sizeof (struct iw_priv_args), + .standard =3D (iw_handler *) prism54_handler, + .private =3D (iw_handler *) prism54_private_handler, + .private_args =3D (struct iw_priv_args *) prism54_private_args, + .spy_offset =3D offsetof(islpci_private, spy_data), +}; + +/* For ioctls that don't work with the new API */ + +int +prism54_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) +{ + + return -EOPNOTSUPP; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_ioctl.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_io= ctl.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_ioctl.h 1970-01-01 00:00:= 00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_ioctl.h 2004-06-2= 3 05:30:04.000000000 +0000 @@ -0,0 +1,54 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * (C) 2003 Aurelien Alleaume + * (C) 2003 Luis R. Rodriguez + * + * 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 + * + * 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 _ISL_IOCTL_H +#define _ISL_IOCTL_H + +#include "islpci_mgt.h" +#include "islpci_dev.h" + +#include /* New driver API */ + +#define SUPPORTED_WIRELESS_EXT 16 + +void prism54_mib_init(islpci_private *); + +struct iw_statistics *prism54_get_wireless_stats(struct net_device *); +void prism54_update_stats(islpci_private *); + +void prism54_acl_init(struct islpci_acl *); +void prism54_acl_clean(struct islpci_acl *); + +void prism54_process_trap(void *); + +void prism54_wpa_ie_init(islpci_private *priv); +void prism54_wpa_ie_clean(islpci_private *priv); +void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len); +size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); + +int prism54_set_mac_address(struct net_device *, void *); + +int prism54_ioctl(struct net_device *, struct ifreq *, int); + +extern const struct iw_handler_def prism54_handler_def; + +#endif /* _ISL_IOCTL_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_oid.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_oid.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_oid.h 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_oid.h 2004-06-23 = 05:30:04.000000000 +0000 @@ -0,0 +1,498 @@ +/* + * + * =20 + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2004 Luis R. Rodriguez + * Copyright (C) 2004 Aurelien Alleaume + * + * 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 + * + * 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 + * + */ + +#if !defined(_ISL_OID_H) +#define _ISL_OID_H + +/*=20 + * MIB related constant and structure definitions for communicating + * with the device firmware + */ + +struct obj_ssid { + u8 length; + char octets[33]; +} __attribute__ ((packed)); + +struct obj_key { + u8 type; /* dot11_priv_t */ + u8 length; + char key[32]; +} __attribute__ ((packed)); + +struct obj_mlme { + u8 address[6]; + u16 id; + u16 state; + u16 code; +} __attribute__ ((packed)); + +struct obj_mlmeex { + u8 address[6]; + u16 id; + u16 state; + u16 code; + u16 size; + u8 data[0]; +} __attribute__ ((packed)); + +struct obj_buffer { + u32 size; + u32 addr; /* 32bit bus address */ +} __attribute__ ((packed)); + +struct obj_bss { + u8 address[6]; + int:16; /* padding */ + + char state; + char reserved; + short age; + + char quality; + char rssi; + + struct obj_ssid ssid; + short channel; + char beacon_period; + char dtim_period; + short capinfo; + short rates; + short basic_rates; + int:16; /* padding */ +} __attribute__ ((packed)); + +struct obj_bsslist { + u32 nr; + struct obj_bss bsslist[0]; +} __attribute__ ((packed)); + +struct obj_frequencies { + u16 nr; + u16 mhz[0]; +} __attribute__ ((packed)); + +/*=20 + * in case everything's ok, the inlined function below will be + * optimized away by the compiler... + */ +static inline void +__bug_on_wrong_struct_sizes(void) +{ + BUG_ON(sizeof (struct obj_ssid) !=3D 34); + BUG_ON(sizeof (struct obj_key) !=3D 34); + BUG_ON(sizeof (struct obj_mlme) !=3D 12); + BUG_ON(sizeof (struct obj_mlmeex) !=3D 14); + BUG_ON(sizeof (struct obj_buffer) !=3D 8); + BUG_ON(sizeof (struct obj_bss) !=3D 60); + BUG_ON(sizeof (struct obj_bsslist) !=3D 4); + BUG_ON(sizeof (struct obj_frequencies) !=3D 2); +} + +enum dot11_state_t { + DOT11_STATE_NONE =3D 0, + DOT11_STATE_AUTHING =3D 1, + DOT11_STATE_AUTH =3D 2, + DOT11_STATE_ASSOCING =3D 3, + + DOT11_STATE_ASSOC =3D 5, + DOT11_STATE_IBSS =3D 6, + DOT11_STATE_WDS =3D 7 +}; + +enum dot11_bsstype_t { + DOT11_BSSTYPE_NONE =3D 0, + DOT11_BSSTYPE_INFRA =3D 1, + DOT11_BSSTYPE_IBSS =3D 2, + DOT11_BSSTYPE_ANY =3D 3 +}; + +enum dot11_auth_t { + DOT11_AUTH_NONE =3D 0, + DOT11_AUTH_OS =3D 1, + DOT11_AUTH_SK =3D 2, + DOT11_AUTH_BOTH =3D 3 +}; + +enum dot11_mlme_t { + DOT11_MLME_AUTO =3D 0, + DOT11_MLME_INTERMEDIATE =3D 1, + DOT11_MLME_EXTENDED =3D 2 +}; + +enum dot11_priv_t { + DOT11_PRIV_WEP =3D 0, + DOT11_PRIV_TKIP =3D 1 +}; + +/* Prism "Nitro" / Frameburst / "Packet Frame Grouping" + * Value is in microseconds. Represents the # microseconds + * the firmware will take to group frames before sending out then out=20 + * together with a CSMA contention. Without this all frames are + * sent with a CSMA contention.=20 + * Bibliography:=20 + * http://www.hpl.hp.com/personal/Jean_Tourrilhes/Papers/Packet.Frame.Grou= ping.html + */ +enum dot11_maxframeburst_t {=20 + /* Values for DOT11_OID_MAXFRAMEBURST */ + DOT11_MAXFRAMEBURST_OFF =3D 0, /* Card firmware default */ + DOT11_MAXFRAMEBURST_MIXED_SAFE =3D 650, /* 802.11 a,b,g safe */ + DOT11_MAXFRAMEBURST_IDEAL =3D 1300, /* Theoretical ideal level */ + DOT11_MAXFRAMEBURST_MAX =3D 5000, /* Use this as max, + * Note: firmware allows for greater values. This is a + * recommended max. I'll update this as I find + * out what the real MAX is. Also note that you don't necessarily + * get better results with a greater value here. + */ +}; + +/* Support for 802.11 long and short frame preambles. + * Long preamble uses 128-bit sync field, 8-bit CRC + * Short preamble uses 56-bit sync field, 16-bit CRC + *=20 + * 802.11a -- not sure, both optionally ? + * 802.11b supports long and optionally short=20 + * 802.11g supports both */ +enum dot11_preamblesettings_t { + DOT11_PREAMBLESETTING_LONG =3D 0, + /* Allows *only* long 802.11 preambles */ + DOT11_PREAMBLESETTING_SHORT =3D 1, + /* Allows *only* short 802.11 preambles */ + DOT11_PREAMBLESETTING_DYNAMIC =3D 2 + /* AutomatiGically set */ +}; + +/* Support for 802.11 slot timing (time between packets). + * + * Long uses 802.11a slot timing (9 usec ?) + * Short uses 802.11b slot timing (20 use ?) */ +enum dot11_slotsettings_t { + DOT11_SLOTSETTINGS_LONG =3D 0,=20 + /* Allows *only* long 802.11b slot timing */ + DOT11_SLOTSETTINGS_SHORT =3D 1, + /* Allows *only* long 802.11a slot timing */ + DOT11_SLOTSETTINGS_DYNAMIC =3D 2 + /* AutomatiGically set */ +}; + +/* All you need to know, ERP is "Extended Rate PHY". + * An Extended Rate PHY (ERP) STA or AP shall support three different=20 + * preamble and header formats: + * Long preamble (refer to above) + * Short preamble (refer to above) + * OFDM preamble ( ? ) + * + * I'm assuming here Protection tells the AP + * to be careful, a STA which cannot handle the long pre-amble + * has joined. + */ +enum do11_nonerpstatus_t { + DOT11_ERPSTAT_NONEPRESENT =3D 0, + DOT11_ERPSTAT_USEPROTECTION =3D 1 +}; + +/* (ERP is "Extended Rate PHY") Way to read NONERP is NON-ERP-* + * The key here is DOT11 NON ERP NEVER protects against + * NON ERP STA's. You *don't* want this unless + * you know what you are doing. It means you will only=20 + * get Extended Rate capabilities */ +enum dot11_nonerpprotection_t { + DOT11_NONERP_NEVER =3D 0, + DOT11_NONERP_ALWAYS =3D 1, + DOT11_NONERP_DYNAMIC =3D 2 +}; + +/* Preset OID configuration for 802.11 modes=20 + * Note: DOT11_OID_CW[MIN|MAX] hold the values of the=20 + * DCS MIN|MAX backoff used */ +enum dot11_profile_t { /* And set/allowed values */ + /* Allowed values for DOT11_OID_PROFILES */ + DOT11_PROFILE_B_ONLY =3D 0, + /* DOT11_OID_RATES: 1, 2, 5.5, 11Mbps=20 + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_DYNAMIC + * DOT11_OID_CWMIN: 31 + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_DYNAMIC + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_LONG + */ + DOT11_PROFILE_MIXED_G_WIFI =3D 1, + /* DOT11_OID_RATES: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54Mbs + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_DYNAMIC + * DOT11_OID_CWMIN: 15 + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_DYNAMIC + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_DYNAMIC + */ + DOT11_PROFILE_MIXED_LONG =3D 2, /* "Long range" */ + /* Same as Profile MIXED_G_WIFI */ + DOT11_PROFILE_G_ONLY =3D 3, + /* Same as Profile MIXED_G_WIFI */ + DOT11_PROFILE_TEST =3D 4, + /* Same as Profile MIXED_G_WIFI except: + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_SHORT + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_NEVER + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_SHORT + */ + DOT11_PROFILE_B_WIFI =3D 5, + /* Same as Profile B_ONLY */ + DOT11_PROFILE_A_ONLY =3D 6, + /* Same as Profile MIXED_G_WIFI except: + * DOT11_OID_RATES: 6, 9, 12, 18, 24, 36, 48, 54Mbs + */ + DOT11_PROFILE_MIXED_SHORT =3D 7 + /* Same as MIXED_G_WIFI */ +}; + + +/* The dot11d conformance level configures the 802.11d conformance levels. + * The following conformance levels exist:*/ +enum oid_inl_conformance_t { + OID_INL_CONFORMANCE_NONE =3D 0, /* Perform active scanning */ + OID_INL_CONFORMANCE_STRICT =3D 1, /* Strictly adhere to 802.11d */ + OID_INL_CONFORMANCE_FLEXIBLE =3D 2, /* Use passed 802.11d info to + * determine channel AND/OR just make assumption that active=20 + * channels are valid channels */ +}; + +enum oid_inl_mode_t { + INL_MODE_NONE =3D -1, + INL_MODE_PROMISCUOUS =3D 0, + INL_MODE_CLIENT =3D 1, + INL_MODE_AP =3D 2, + INL_MODE_SNIFFER =3D 3 +}; + +enum oid_inl_config_t { + INL_CONFIG_NOTHING =3D 0x00, + INL_CONFIG_MANUALRUN =3D 0x01, + INL_CONFIG_FRAMETRAP =3D 0x02, + INL_CONFIG_RXANNEX =3D 0x04, + INL_CONFIG_TXANNEX =3D 0x08, + INL_CONFIG_WDS =3D 0x10 +}; + +enum oid_inl_phycap_t { + INL_PHYCAP_2400MHZ =3D 1, + INL_PHYCAP_5000MHZ =3D 2, + INL_PHYCAP_FAA =3D 0x80000000, /* Means card supports the FAA switch */ +}; + + +enum oid_num_t { + GEN_OID_MACADDRESS =3D 0, + GEN_OID_LINKSTATE, + GEN_OID_WATCHDOG, + GEN_OID_MIBOP, + GEN_OID_OPTIONS, + GEN_OID_LEDCONFIG, + + /* 802.11 */ + DOT11_OID_BSSTYPE, + DOT11_OID_BSSID, + DOT11_OID_SSID, + DOT11_OID_STATE, + DOT11_OID_AID, + DOT11_OID_COUNTRYSTRING, + DOT11_OID_SSIDOVERRIDE, + + DOT11_OID_MEDIUMLIMIT, + DOT11_OID_BEACONPERIOD, + DOT11_OID_DTIMPERIOD, + DOT11_OID_ATIMWINDOW, + DOT11_OID_LISTENINTERVAL, + DOT11_OID_CFPPERIOD, + DOT11_OID_CFPDURATION, + + DOT11_OID_AUTHENABLE, + DOT11_OID_PRIVACYINVOKED, + DOT11_OID_EXUNENCRYPTED, + DOT11_OID_DEFKEYID, + DOT11_OID_DEFKEYX, /* DOT11_OID_DEFKEY1,...DOT11_OID_DEFKEY4 */ + DOT11_OID_STAKEY, + DOT11_OID_REKEYTHRESHOLD, + DOT11_OID_STASC, + + DOT11_OID_PRIVTXREJECTED, + DOT11_OID_PRIVRXPLAIN, + DOT11_OID_PRIVRXFAILED, + DOT11_OID_PRIVRXNOKEY, + + DOT11_OID_RTSTHRESH, + DOT11_OID_FRAGTHRESH, + DOT11_OID_SHORTRETRIES, + DOT11_OID_LONGRETRIES, + DOT11_OID_MAXTXLIFETIME, + DOT11_OID_MAXRXLIFETIME, + DOT11_OID_AUTHRESPTIMEOUT, + DOT11_OID_ASSOCRESPTIMEOUT, + + DOT11_OID_ALOFT_TABLE, + DOT11_OID_ALOFT_CTRL_TABLE, + DOT11_OID_ALOFT_RETREAT, + DOT11_OID_ALOFT_PROGRESS, + DOT11_OID_ALOFT_FIXEDRATE, + DOT11_OID_ALOFT_RSSIGRAPH, + DOT11_OID_ALOFT_CONFIG, + + DOT11_OID_VDCFX, + DOT11_OID_MAXFRAMEBURST, + + DOT11_OID_PSM, + DOT11_OID_CAMTIMEOUT, + DOT11_OID_RECEIVEDTIMS, + DOT11_OID_ROAMPREFERENCE, + + DOT11_OID_BRIDGELOCAL, + DOT11_OID_CLIENTS, + DOT11_OID_CLIENTSASSOCIATED, + DOT11_OID_CLIENTX, /* DOT11_OID_CLIENTX,...DOT11_OID_CLIENT2007 */ + + DOT11_OID_CLIENTFIND, + DOT11_OID_WDSLINKADD, + DOT11_OID_WDSLINKREMOVE, + DOT11_OID_EAPAUTHSTA, + DOT11_OID_EAPUNAUTHSTA, + DOT11_OID_DOT1XENABLE, + DOT11_OID_MICFAILURE, + DOT11_OID_REKEYINDICATE, + + DOT11_OID_MPDUTXSUCCESSFUL, + DOT11_OID_MPDUTXONERETRY, + DOT11_OID_MPDUTXMULTIPLERETRIES, + DOT11_OID_MPDUTXFAILED, + DOT11_OID_MPDURXSUCCESSFUL, + DOT11_OID_MPDURXDUPS, + DOT11_OID_RTSSUCCESSFUL, + DOT11_OID_RTSFAILED, + DOT11_OID_ACKFAILED, + DOT11_OID_FRAMERECEIVES, + DOT11_OID_FRAMEERRORS, + DOT11_OID_FRAMEABORTS, + DOT11_OID_FRAMEABORTSPHY, + + DOT11_OID_SLOTTIME, + DOT11_OID_CWMIN, /* MIN DCS backoff */ + DOT11_OID_CWMAX, /* MAX DCS backoff */ + DOT11_OID_ACKWINDOW, + DOT11_OID_ANTENNARX, + DOT11_OID_ANTENNATX, + DOT11_OID_ANTENNADIVERSITY, + DOT11_OID_CHANNEL, + DOT11_OID_EDTHRESHOLD, + DOT11_OID_PREAMBLESETTINGS, + DOT11_OID_RATES, + DOT11_OID_CCAMODESUPPORTED, + DOT11_OID_CCAMODE, + DOT11_OID_RSSIVECTOR, + DOT11_OID_OUTPUTPOWERTABLE, + DOT11_OID_OUTPUTPOWER, + DOT11_OID_SUPPORTEDRATES, + DOT11_OID_FREQUENCY, + DOT11_OID_SUPPORTEDFREQUENCIES, + DOT11_OID_NOISEFLOOR, + DOT11_OID_FREQUENCYACTIVITY, + DOT11_OID_IQCALIBRATIONTABLE, + DOT11_OID_NONERPPROTECTION, + DOT11_OID_SLOTSETTINGS, + DOT11_OID_NONERPTIMEOUT, + DOT11_OID_PROFILES, + DOT11_OID_EXTENDEDRATES, + + DOT11_OID_DEAUTHENTICATE, + DOT11_OID_AUTHENTICATE, + DOT11_OID_DISASSOCIATE, + DOT11_OID_ASSOCIATE, + DOT11_OID_SCAN, + DOT11_OID_BEACON, + DOT11_OID_PROBE, + DOT11_OID_DEAUTHENTICATEEX, + DOT11_OID_AUTHENTICATEEX, + DOT11_OID_DISASSOCIATEEX, + DOT11_OID_ASSOCIATEEX, + DOT11_OID_REASSOCIATE, + DOT11_OID_REASSOCIATEEX, + + DOT11_OID_NONERPSTATUS, + + DOT11_OID_STATIMEOUT, + DOT11_OID_MLMEAUTOLEVEL, + DOT11_OID_BSSTIMEOUT, + DOT11_OID_ATTACHMENT, + DOT11_OID_PSMBUFFER, + + DOT11_OID_BSSS, + DOT11_OID_BSSX, /*DOT11_OID_BSS1,...,DOT11_OID_BSS64 */ + DOT11_OID_BSSFIND, + DOT11_OID_BSSLIST, + + OID_INL_TUNNEL, + OID_INL_MEMADDR, + OID_INL_MEMORY, + OID_INL_MODE, + OID_INL_COMPONENT_NR, + OID_INL_VERSION, + OID_INL_INTERFACE_ID, + OID_INL_COMPONENT_ID, + OID_INL_CONFIG, + OID_INL_DOT11D_CONFORMANCE, + OID_INL_PHYCAPABILITIES, + OID_INL_OUTPUTPOWER, + + OID_NUM_LAST +}; + +#define OID_FLAG_CACHED 0x80 +#define OID_FLAG_TYPE 0x7f + +#define OID_TYPE_U32 0x01 +#define OID_TYPE_SSID 0x02 +#define OID_TYPE_KEY 0x03 +#define OID_TYPE_BUFFER 0x04 +#define OID_TYPE_BSS 0x05 +#define OID_TYPE_BSSLIST 0x06 +#define OID_TYPE_FREQUENCIES 0x07 +#define OID_TYPE_MLME 0x08 +#define OID_TYPE_MLMEEX 0x09 +#define OID_TYPE_ADDR 0x0A +#define OID_TYPE_RAW 0x0B + +/* OID_TYPE_MLMEEX is special because of a variable size field when sendin= g. + * Not yet implemented (not used in driver anyway). + */ + +struct oid_t { + enum oid_num_t oid; + short range; /* to define a range of oid */ + short size; /* max size of the associated data */ + char flags; +}; + +union oid_res_t { + void *ptr; + u32 u; +}; + +#define IWMAX_BITRATES 20 +#define IWMAX_BSS 24 +#define IWMAX_FREQ 30 +#define PRIV_STR_SIZE 1024 + +#endif /* !defined(_ISL_OID_H) */ +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_dev.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_dev.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_dev.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_dev.c 2004-06-= 23 05:30:04.000000000 +0000 @@ -0,0 +1,928 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2003 Luis R. Rodriguez + * + * 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 + * + * 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 "prismcompat.h" +#include "isl_38xx.h" +#include "isl_ioctl.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" +#include "islpci_eth.h" +#include "oid_mgt.h" + +#define ISL3877_IMAGE_FILE "isl3877" +#define ISL3890_IMAGE_FILE "isl3890" + +/* Temporary dummy MAC address to use until firmware is loaded. + * The idea there is that some tools (such as nameif) may query + * the MAC address before the netdev is 'open'. By using a valid + * OUI prefix, they can process the netdev properly. + * Of course, this is not the final/real MAC address. It doesn't + * matter, as you are suppose to be able to change it anytime via + * ndev->set_mac_address. Jean II */ +const unsigned char dummy_mac[6] =3D { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 = }; + +static int +isl_upload_firmware(islpci_private *priv) +{ + u32 reg, rc; + void *device_base =3D priv->device_base; + + /* clear the RAMBoot and the Reset bit */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + reg &=3D ~ISL38XX_CTRL_STAT_RAMBOOT; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the Reset bit without reading the register ! */ + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reboot */ + mdelay(50); + + { + const struct firmware *fw_entry =3D 0; + long fw_len; + const u32 *fw_ptr; + + rc =3D request_firmware(&fw_entry, priv->firmware, PRISM_FW_PDEV); + if (rc) { + printk(KERN_ERR + "%s: request_firmware() failed for '%s'\n", + "prism54", priv->firmware); + return rc; + } + /* prepare the Direct Memory Base register */ + reg =3D ISL38XX_DEV_FIRMWARE_ADDRES; + + fw_ptr =3D (u32 *) fw_entry->data; + fw_len =3D fw_entry->size; + + if (fw_len % 4) { + printk(KERN_ERR + "%s: firmware '%s' size is not multiple of 32bit, aborting!\n", + "prism54", priv->firmware); + release_firmware(fw_entry); + return EILSEQ; /* Illegal byte sequence */; + } + + while (fw_len > 0) { + long _fw_len =3D + (fw_len > + ISL38XX_MEMORY_WINDOW_SIZE) ? + ISL38XX_MEMORY_WINDOW_SIZE : fw_len; + u32 *dev_fw_ptr =3D device_base + ISL38XX_DIRECT_MEM_WIN; + + /* set the cards base address for writting the data */ + isl38xx_w32_flush(device_base, reg, + ISL38XX_DIR_MEM_BASE_REG); + wmb(); /* be paranoid */ + + /* increment the write address for next iteration */ + reg +=3D _fw_len; + fw_len -=3D _fw_len; + + /* write the data to the Direct Memory Window 32bit-wise */ + /* memcpy_toio() doesn't guarantee 32bit writes :-| */ + while (_fw_len > 0) { + /* use non-swapping writel() */ + __raw_writel(*fw_ptr, dev_fw_ptr); + fw_ptr++, dev_fw_ptr++; + _fw_len -=3D 4; + } + + /* flush PCI posting */ + (void) readl(device_base + ISL38XX_PCI_POSTING_FLUSH); + wmb(); /* be paranoid again */ + + BUG_ON(_fw_len !=3D 0); + } + + BUG_ON(fw_len !=3D 0); + + release_firmware(fw_entry); + } + + /* now reset the device + * clear the Reset & ClkRun bit, set the RAMBoot bit */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~ISL38XX_CTRL_STAT_CLKRUN; + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + reg |=3D ISL38XX_CTRL_STAT_RAMBOOT; + isl38xx_w32_flush(device_base, reg, ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the reset bit latches the host override and RAMBoot bits + * into the device for operation when the reset bit is reset */ + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the reset bit should start the whole circus */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + return 0; +} + +/*************************************************************************= ***** + Device Interrupt Handler +**************************************************************************= ****/ + +irqreturn_t +islpci_interrupt(int irq, void *config, struct pt_regs *regs) +{ + u32 reg; + islpci_private *priv =3D config; + struct net_device *ndev =3D priv->ndev; + void *device =3D priv->device_base; + int powerstate =3D ISL38XX_PSM_POWERSAVE_STATE; + + /* received an interrupt request on a shared IRQ line + * first check whether the device is in sleep mode */ + reg =3D readl(device + ISL38XX_CTRL_STAT_REG); + if (reg & ISL38XX_CTRL_STAT_SLEEPMODE) + /* device is in sleep mode, IRQ was generated by someone else */ + { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); +#endif + return IRQ_NONE; + } + + if (islpci_get_state(priv) !=3D PRV_STATE_SLEEP) + powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* lock the interrupt handler */ + spin_lock(&priv->slock); + + /* check whether there is any source of interrupt on the device */ + reg =3D readl(device + ISL38XX_INT_IDENT_REG); + + /* also check the contents of the Interrupt Enable Register, because this + * will filter out interrupt sources from other devices on the same irq != */ + reg &=3D readl(device + ISL38XX_INT_EN_REG); + reg &=3D ISL38XX_INT_SOURCES; + + if (reg !=3D 0) { + /* reset the request bits in the Identification register */ + isl38xx_w32_flush(device, reg, ISL38XX_INT_ACK_REG); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, + "IRQ: Identification register 0x%p 0x%x \n", device, reg); +#endif + + /* check for each bit in the register separately */ + if (reg & ISL38XX_INT_IDENT_UPDATE) { +#if VERBOSE > SHOW_ERROR_MESSAGES + /* Queue has been updated */ + DEBUG(SHOW_TRACING, "IRQ: Update flag \n"); + + DEBUG(SHOW_QUEUE_INDEXES, + "CB drv Qs: [%i][%i][%i][%i][%i][%i]\n", + le32_to_cpu(priv->control_block-> + driver_curr_frag[0]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[1]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[2]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[3]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[4]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[5]) + ); + + DEBUG(SHOW_QUEUE_INDEXES, + "CB dev Qs: [%i][%i][%i][%i][%i][%i]\n", + le32_to_cpu(priv->control_block-> + device_curr_frag[0]), + le32_to_cpu(priv->control_block-> + device_curr_frag[1]), + le32_to_cpu(priv->control_block-> + device_curr_frag[2]), + le32_to_cpu(priv->control_block-> + device_curr_frag[3]), + le32_to_cpu(priv->control_block-> + device_curr_frag[4]), + le32_to_cpu(priv->control_block-> + device_curr_frag[5]) + ); +#endif + + /* cleanup the data low transmit queue */ + islpci_eth_cleanup_transmit(priv, priv->control_block); + + /* device is in active state, update the + * powerstate flag if necessary */ + powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* check all three queues in priority order + * call the PIMFOR receive function until the + * queue is empty */ + if (isl38xx_in_queue(priv->control_block, + ISL38XX_CB_RX_MGMTQ) !=3D 0) { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "Received frame in Management Queue\n"); +#endif + islpci_mgt_receive(ndev); + + islpci_mgt_cleanup_transmit(ndev); + + /* Refill slots in receive queue */ + islpci_mgmt_rx_fill(ndev); + + /* no need to trigger the device, next + islpci_mgt_transaction does it */ + } + + while (isl38xx_in_queue(priv->control_block, + ISL38XX_CB_RX_DATA_LQ) !=3D 0) { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "Received frame in Data Low Queue \n"); +#endif + islpci_eth_receive(priv); + } + + /* check whether the data transmit queues were full */ + if (priv->data_low_tx_full) { + /* check whether the transmit is not full anymore */ + if (ISL38XX_CB_TX_QSIZE - + isl38xx_in_queue(priv->control_block, + ISL38XX_CB_TX_DATA_LQ) >=3D + ISL38XX_MIN_QTHRESHOLD) { + /* nope, the driver is ready for more network frames */ + netif_wake_queue(priv->ndev); + + /* reset the full flag */ + priv->data_low_tx_full =3D 0; + } + } + } + + if (reg & ISL38XX_INT_IDENT_INIT) { + /* Device has been initialized */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "IRQ: Init flag, device initialized \n"); +#endif + wake_up(&priv->reset_done); + } + + if (reg & ISL38XX_INT_IDENT_SLEEP) { + /* Device intends to move to powersave state */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "IRQ: Sleep flag \n"); +#endif + isl38xx_handle_sleep_request(priv->control_block, + &powerstate, + priv->device_base); + } + + if (reg & ISL38XX_INT_IDENT_WAKEUP) { + /* Device has been woken up to active state */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "IRQ: Wakeup flag \n"); +#endif + + isl38xx_handle_wakeup(priv->control_block, + &powerstate, priv->device_base); + } + } + + /* sleep -> ready */ + if (islpci_get_state(priv) =3D=3D PRV_STATE_SLEEP + && powerstate =3D=3D ISL38XX_PSM_ACTIVE_STATE) + islpci_set_state(priv, PRV_STATE_READY); + + /* !sleep -> sleep */ + if (islpci_get_state(priv) !=3D PRV_STATE_SLEEP + && powerstate =3D=3D ISL38XX_PSM_POWERSAVE_STATE) + islpci_set_state(priv, PRV_STATE_SLEEP); + + /* unlock the interrupt handler */ + spin_unlock(&priv->slock); + + return IRQ_HANDLED; +} + +/*************************************************************************= ***** + Network Interface Control & Statistical functions +**************************************************************************= ****/ +static int +islpci_open(struct net_device *ndev) +{ + u32 rc; + islpci_private *priv =3D netdev_priv(ndev); + + printk(KERN_DEBUG "%s: islpci_open()\n", ndev->name); + + /* reset data structures, upload firmware and reset device */ + rc =3D islpci_reset(priv,1); + if (rc) { + prism54_bring_down(priv); + return rc; /* Returns informative message */ + } + + netif_start_queue(ndev); +/* netif_mark_up( ndev ); */ + + return 0; +} + +static int +islpci_close(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + + printk(KERN_DEBUG "%s: islpci_close ()\n", ndev->name); + + netif_stop_queue(ndev); + + return prism54_bring_down(priv); +} + +int +prism54_bring_down(islpci_private *priv) +{ + void *device_base =3D priv->device_base; + u32 reg; + /* we are going to shutdown the device */ + islpci_set_state(priv, PRV_STATE_PREBOOT); + + /* disable all device interrupts in case they weren't */ + isl38xx_disable_interrupts(priv->device_base); =20 + + /* For safety reasons, we may want to ensure that no DMA transfer is + * currently in progress by emptying the TX and RX queues. */ + + /* wait until interrupts have finished executing on other CPUs */ + prism54_synchronize_irq(priv->pdev->irq); + + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~(ISL38XX_CTRL_STAT_RESET | ISL38XX_CTRL_STAT_RAMBOOT); + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reset */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(50*HZ/1000); + + return 0; +} + +static int +islpci_upload_fw(islpci_private *priv) +{ + islpci_state_t old_state; + u32 rc; + + old_state =3D islpci_set_state(priv, PRV_STATE_BOOT); + + printk(KERN_DEBUG "%s: uploading firmware...\n", priv->ndev->name); + + rc =3D isl_upload_firmware(priv); + if (rc) { + /* error uploading the firmware */ + printk(KERN_ERR "%s: could not upload firmware ('%s')\n", + priv->ndev->name, priv->firmware); + + islpci_set_state(priv, old_state); + return rc; + } + + printk(KERN_DEBUG + "%s: firmware uploaded done, now triggering reset...\n", + priv->ndev->name); + + islpci_set_state(priv, PRV_STATE_POSTBOOT); + + return 0; +} + +static int +islpci_reset_if(islpci_private *priv) +{ + long remaining; + int result =3D -ETIME; + int count; + + DEFINE_WAIT(wait); + prepare_to_wait(&priv->reset_done, &wait, TASK_UNINTERRUPTIBLE); +=09 + /* now the last step is to reset the interface */ + isl38xx_interface_reset(priv->device_base, priv->device_host_address); + islpci_set_state(priv, PRV_STATE_PREINIT); + + for(count =3D 0; count < 2 && result; count++) { + /* The software reset acknowledge needs about 220 msec here. + * Be conservative and wait for up to one second. */ +=09 + remaining =3D schedule_timeout(HZ); + + if(remaining > 0) { + result =3D 0; + break; + } + + /* If we're here it's because our IRQ hasn't yet gone through.=20 + * Retry a bit more... + */ + printk(KERN_ERR "%s: device soft reset timed out\n", + priv->ndev->name); + + } + + finish_wait(&priv->reset_done, &wait); + + if(result) + return result; + + islpci_set_state(priv, PRV_STATE_INIT); + + /* Now that the device is 100% up, let's allow + * for the other interrupts -- + * NOTE: this is not *yet* true since we've only allowed the=20 + * INIT interrupt on the IRQ line. We can perhaps poll + * the IRQ line until we know for sure the reset went through */ + isl38xx_enable_common_interrupts(priv->device_base); + + down_write(&priv->mib_sem); + mgt_commit(priv); + up_write(&priv->mib_sem); + + islpci_set_state(priv, PRV_STATE_READY); + + return 0; +} + +int +islpci_reset(islpci_private *priv, int reload_firmware) +{ + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + unsigned counter; + int rc; + + if (reload_firmware) + islpci_set_state(priv, PRV_STATE_PREBOOT); + else + islpci_set_state(priv, PRV_STATE_POSTBOOT); + + printk(KERN_DEBUG "%s: resetting device...\n", priv->ndev->name); + + /* disable all device interrupts in case they weren't */ + isl38xx_disable_interrupts(priv->device_base); + + /* flush all management queues */ + priv->index_mgmt_tx =3D 0; + priv->index_mgmt_rx =3D 0; + + /* clear the indexes in the frame pointer */ + for (counter =3D 0; counter < ISL38XX_CB_QCOUNT; counter++) { + cb->driver_curr_frag[counter] =3D cpu_to_le32(0); + cb->device_curr_frag[counter] =3D cpu_to_le32(0); + } + + /* reset the mgmt receive queue */ + for (counter =3D 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { + isl38xx_fragment *frag =3D &cb->rx_data_mgmt[counter]; + frag->size =3D cpu_to_le16(MGMT_FRAME_SIZE); + frag->flags =3D 0; + frag->address =3D cpu_to_le32(priv->mgmt_rx[counter].pci_addr); + } + + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + cb->rx_data_low[counter].address =3D + cpu_to_le32((u32) priv->pci_map_rx_address[counter]); + } + + /* since the receive queues are filled with empty fragments, now we can + * set the corresponding indexes in the Control Block */ + priv->control_block->driver_curr_frag[ISL38XX_CB_RX_DATA_LQ] =3D + cpu_to_le32(ISL38XX_CB_RX_QSIZE); + priv->control_block->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] =3D + cpu_to_le32(ISL38XX_CB_MGMT_QSIZE); + + /* reset the remaining real index registers and full flags */ + priv->free_data_rx =3D 0; + priv->free_data_tx =3D 0; + priv->data_low_tx_full =3D 0; + + if (reload_firmware) { /* Should we load the firmware ? */ + /* now that the data structures are cleaned up, upload + * firmware and reset interface */ + rc =3D islpci_upload_fw(priv); + if (rc)=20 + return rc; + } + + /* finally reset interface */ + rc =3D islpci_reset_if(priv); + if (!rc) /* If successful */ + return rc; +=09 + printk(KERN_DEBUG "prism54: Your card/socket may be faulty, or IRQ line = too busy :(\n"); + return rc; + +} + +struct net_device_stats * +islpci_statistics(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_statistics \n"); +#endif + + return &priv->statistics; +} + +/*************************************************************************= ***** + Network device configuration functions +**************************************************************************= ****/ +int +islpci_alloc_memory(islpci_private *priv) +{ + int counter; + +#if VERBOSE > SHOW_ERROR_MESSAGES + printk(KERN_DEBUG "islpci_alloc_memory\n"); +#endif + + /* remap the PCI device base address to accessable */ + if (!(priv->device_base =3D + ioremap(pci_resource_start(priv->pdev, 0), + ISL38XX_PCI_MEM_SIZE))) { + /* error in remapping the PCI device memory address range */ + printk(KERN_ERR "PCI memory remapping failed \n"); + return -1; + } + + /* memory layout for consistent DMA region: + * + * Area 1: Control Block for the device interface + * Area 2: Power Save Mode Buffer for temporary frame storage. Be aware t= hat + * the number of supported stations in the AP determines the mini= mal + * size of the buffer ! + */ + + /* perform the allocation */ + priv->driver_mem_address =3D pci_alloc_consistent(priv->pdev, + HOST_MEM_BLOCK, + &priv-> + device_host_address); + + if (!priv->driver_mem_address) { + /* error allocating the block of PCI memory */ + printk(KERN_ERR "%s: could not allocate DMA memory, aborting!", + "prism54"); + return -1; + } + + /* assign the Control Block to the first address of the allocated area */ + priv->control_block =3D + (isl38xx_control_block *) priv->driver_mem_address; + + /* set the Power Save Buffer pointer directly behind the CB */ + priv->device_psm_buffer =3D + priv->device_host_address + CONTROL_BLOCK_SIZE; + + /* make sure all buffer pointers are initialized */ + for (counter =3D 0; counter < ISL38XX_CB_QCOUNT; counter++) { + priv->control_block->driver_curr_frag[counter] =3D cpu_to_le32(0); + priv->control_block->device_curr_frag[counter] =3D cpu_to_le32(0); + } + + priv->index_mgmt_rx =3D 0; + memset(priv->mgmt_rx, 0, sizeof(priv->mgmt_rx)); + memset(priv->mgmt_tx, 0, sizeof(priv->mgmt_tx)); + + /* allocate rx queue for management frames */ + if (islpci_mgmt_rx_fill(priv->ndev) < 0) + goto out_free; + + /* now get the data rx skb's */ + memset(priv->data_low_rx, 0, sizeof (priv->data_low_rx)); + memset(priv->pci_map_rx_address, 0, sizeof (priv->pci_map_rx_address)); + + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + struct sk_buff *skb; + + /* allocate an sk_buff for received data frames storage + * each frame on receive size consists of 1 fragment + * include any required allignment operations */ + if (!(skb =3D dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2))) { + /* error allocating an sk_buff structure elements */ + printk(KERN_ERR "Error allocating skb.\n"); + skb =3D NULL; + goto out_free; + } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + /* add the new allocated sk_buff to the buffer array */ + priv->data_low_rx[counter] =3D skb; + + /* map the allocated skb data area to pci */ + priv->pci_map_rx_address[counter] =3D + pci_map_single(priv->pdev, (void *) skb->data, + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + if (!priv->pci_map_rx_address[counter]) { + /* error mapping the buffer to device + accessable memory address */ + printk(KERN_ERR "failed to map skb DMA'able\n"); + goto out_free; + } + } + + prism54_acl_init(&priv->acl); + prism54_wpa_ie_init(priv); + if (mgt_init(priv))=20 + goto out_free; + + return 0; + out_free: + islpci_free_memory(priv); + return -1; +} + +int +islpci_free_memory(islpci_private *priv) +{ + int counter; + + if (priv->device_base) + iounmap(priv->device_base); + priv->device_base =3D 0; + + /* free consistent DMA area... */ + if (priv->driver_mem_address) + pci_free_consistent(priv->pdev, HOST_MEM_BLOCK, + priv->driver_mem_address, + priv->device_host_address); + + /* clear some dangling pointers */ + priv->driver_mem_address =3D 0; + priv->device_host_address =3D 0; + priv->device_psm_buffer =3D 0; + priv->control_block =3D 0; + + /* clean up mgmt rx buffers */ + for (counter =3D 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { + struct islpci_membuf *buf =3D &priv->mgmt_rx[counter]; + if (buf->pci_addr) + pci_unmap_single(priv->pdev, buf->pci_addr, + buf->size, PCI_DMA_FROMDEVICE); + buf->pci_addr =3D 0; + if (buf->mem) + kfree(buf->mem); + buf->size =3D 0; + buf->mem =3D NULL; + } + + /* clean up data rx buffers */ + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + if (priv->pci_map_rx_address[counter]) + pci_unmap_single(priv->pdev, + priv->pci_map_rx_address[counter], + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + priv->pci_map_rx_address[counter] =3D 0; + + if (priv->data_low_rx[counter]) + dev_kfree_skb(priv->data_low_rx[counter]); + priv->data_low_rx[counter] =3D 0; + } + + /* Free the acces control list and the WPA list */ + prism54_acl_clean(&priv->acl); + prism54_wpa_ie_clean(priv); + mgt_clean(priv); + + return 0; +} + +#if 0 +static void +islpci_set_multicast_list(struct net_device *dev) +{ + /* put device into promisc mode and let network layer handle it */ +} +#endif + +struct net_device * +islpci_setup(struct pci_dev *pdev) +{ + islpci_private *priv; + struct net_device *ndev =3D alloc_etherdev(sizeof (islpci_private)); + + if (!ndev) + return ndev; + + SET_MODULE_OWNER(ndev); + pci_set_drvdata(pdev, ndev); +#if defined(SET_NETDEV_DEV) + SET_NETDEV_DEV(ndev, &pdev->dev); +#endif + + /* setup the structure members */ + ndev->base_addr =3D pci_resource_start(pdev, 0); + ndev->irq =3D pdev->irq; + + /* initialize the function pointers */ + ndev->open =3D &islpci_open; + ndev->stop =3D &islpci_close; + ndev->get_stats =3D &islpci_statistics; + ndev->get_wireless_stats =3D &prism54_get_wireless_stats; + ndev->do_ioctl =3D &prism54_ioctl; + ndev->wireless_handlers =3D + (struct iw_handler_def *) &prism54_handler_def; + + ndev->hard_start_xmit =3D &islpci_eth_transmit; + /* ndev->set_multicast_list =3D &islpci_set_multicast_list; */ + ndev->addr_len =3D ETH_ALEN; + ndev->set_mac_address =3D &prism54_set_mac_address; + /* Get a non-zero dummy MAC address for nameif. Jean II */ + memcpy(ndev->dev_addr, dummy_mac, 6); + +#ifdef HAVE_TX_TIMEOUT + ndev->watchdog_timeo =3D ISLPCI_TX_TIMEOUT; + ndev->tx_timeout =3D &islpci_eth_tx_timeout; +#endif + + /* allocate a private device structure to the network device */ + priv =3D netdev_priv(ndev); + priv->ndev =3D ndev; + priv->pdev =3D pdev; + priv->monitor_type =3D ARPHRD_IEEE80211; + priv->ndev->type =3D (priv->iw_mode =3D=3D IW_MODE_MONITOR) ? + priv->monitor_type : ARPHRD_ETHER; + + /* save the start and end address of the PCI memory area */ + ndev->mem_start =3D (unsigned long) priv->device_base; + ndev->mem_end =3D ndev->mem_start + ISL38XX_PCI_MEM_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "PCI Memory remapped to 0x%p\n", priv->device_base); +#endif + + init_waitqueue_head(&priv->reset_done); + + /* init the queue read locks, process wait counter */ + sema_init(&priv->mgmt_sem, 1); + priv->mgmt_received =3D NULL; + init_waitqueue_head(&priv->mgmt_wqueue); + sema_init(&priv->stats_sem, 1); + spin_lock_init(&priv->slock); + + /* init state machine with off#1 state */ + priv->state =3D PRV_STATE_OFF; + priv->state_off =3D 1; + + /* initialize workqueue's */ + INIT_WORK(&priv->stats_work, + (void (*)(void *)) prism54_update_stats, priv); + priv->stats_timestamp =3D 0; + + INIT_WORK(&priv->reset_task, islpci_do_reset_and_wake, priv); + priv->reset_task_pending =3D 0; + + /* allocate various memory areas */ + if (islpci_alloc_memory(priv)) + goto do_free_netdev; + + /* 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: + strcpy(priv->firmware, ISL3877_IMAGE_FILE); + break; + + default: + strcpy(priv->firmware, ISL3890_IMAGE_FILE); + break; + } + + if (register_netdev(ndev)) { + DEBUG(SHOW_ERROR_MESSAGES, + "ERROR: register_netdev() failed \n"); + goto do_islpci_free_memory; + } + + return ndev; + + do_islpci_free_memory: + islpci_free_memory(priv); + do_free_netdev: + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + return NULL; +} + +islpci_state_t +islpci_set_state(islpci_private *priv, islpci_state_t new_state) +{ + islpci_state_t old_state; + + /* lock */ + old_state =3D priv->state; + + /* this means either a race condition or some serious error in + * the driver code */ + switch (new_state) { + case PRV_STATE_OFF: + priv->state_off++; + default: + priv->state =3D new_state; + break; + + case PRV_STATE_PREBOOT: + /* there are actually many off-states, enumerated by + * state_off */ + if (old_state =3D=3D PRV_STATE_OFF) + priv->state_off--; + + /* only if hw_unavailable is zero now it means we either + * were in off#1 state, or came here from + * somewhere else */ + if (!priv->state_off) + priv->state =3D new_state; + break; + }; +#if 0 + printk(KERN_DEBUG "%s: state transition %d -> %d (off#%d)\n", + priv->ndev->name, old_state, new_state, priv->state_off); +#endif + + /* invariants */ + BUG_ON(priv->state_off < 0); + BUG_ON(priv->state_off && (priv->state !=3D PRV_STATE_OFF)); + BUG_ON(!priv->state_off && (priv->state =3D=3D PRV_STATE_OFF)); + + /* unlock */ + return old_state; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_dev.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_dev.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_dev.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_dev.h 2004-06-= 23 05:30:04.000000000 +0000 @@ -0,0 +1,217 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc.=20 + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2003 Luis R. Rodriguez + * Copyright (C) 2003 Aurelien Alleaume + * + * 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 + * + * 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 _ISLPCI_DEV_H +#define _ISLPCI_DEV_H + +#include +#include +#include +#include +#include + +#include "isl_38xx.h" +#include "isl_oid.h" +#include "islpci_mgt.h" + +/* some states might not be superflous and may be removed when + design is finalized (hvr) */ +typedef enum { + PRV_STATE_OFF =3D 0, /* this means hw_unavailable is !=3D 0 */ + PRV_STATE_PREBOOT, /* we are in a pre-boot state (empty RAM) */ + PRV_STATE_BOOT, /* boot state (fw upload, run fw) */ + PRV_STATE_POSTBOOT, /* after boot state, need reset now */ + PRV_STATE_PREINIT, /* pre-init state */ + PRV_STATE_INIT, /* init state (restore MIB backup to device) */ + PRV_STATE_READY, /* driver&device are in operational state */ + PRV_STATE_SLEEP /* device in sleep mode */ +} islpci_state_t; + +/* ACL using MAC address */ +struct mac_entry { + struct list_head _list; + char addr[ETH_ALEN]; +}; + +struct islpci_acl { + enum { MAC_POLICY_OPEN=3D0, MAC_POLICY_ACCEPT=3D1, MAC_POLICY_REJECT=3D= 2 } policy; + struct list_head mac_list; /* a list of mac_entry */ + int size; /* size of queue */ + struct semaphore sem; /* accessed in ioctls and trap_work */ +}; + +struct islpci_membuf { + int size; /* size of memory */ + void *mem; /* address of memory as seen by CPU */ + dma_addr_t pci_addr; /* address of memory as seen by device */ +}; + +#define MAX_BSS_WPA_IE_COUNT 64 +#define MAX_WPA_IE_LEN 64 +struct islpci_bss_wpa_ie { + struct list_head list; + unsigned long last_update; + u8 bssid[ETH_ALEN]; + u8 wpa_ie[MAX_WPA_IE_LEN]; + size_t wpa_ie_len; +=09 +}; + +typedef struct { + spinlock_t slock; /* generic spinlock; */ +=09 + u32 priv_oid; + + /* our mib cache */ + u32 iw_mode; + struct rw_semaphore mib_sem; + void **mib; + char nickname[IW_ESSID_MAX_SIZE+1]; +=09 + /* Take care of the wireless stats */ + struct work_struct stats_work; + struct semaphore stats_sem; + /* remember when we last updated the stats */ + unsigned long stats_timestamp; + /* The first is accessed under semaphore locking. + * The second is the clean one we return to iwconfig. + */ + struct iw_statistics local_iwstatistics; + struct iw_statistics iwstatistics; + + struct iw_spy_data spy_data; /* iwspy support */ + + int monitor_type; /* ARPHRD_IEEE80211 or ARPHRD_IEEE80211_PRISM */ + + struct islpci_acl acl; + + /* PCI bus allocation & configuration members */ + struct pci_dev *pdev; /* PCI structure information */ + u32 pci_state[16]; /* used for suspend/resume */ + char firmware[33]; + + void *device_base; /* ioremapped device base address */ + + /* consistent DMA region */ + void *driver_mem_address; /* base DMA address */ + dma_addr_t device_host_address; /* base DMA address (bus address) */ + dma_addr_t device_psm_buffer; /* host memory for PSM buffering (bus addre= ss) */ + + /* our network_device structure */ + struct net_device *ndev; + + /* device queue interface members */ + struct isl38xx_cb *control_block; /* device control block=20 + (=3D=3D driver_mem_address!) */ + + /* Each queue has three indexes: + * free/index_mgmt/data_rx/tx (called index, see below), + * driver_curr_frag, and device_curr_frag (in the control block) + * All indexes are ever-increasing, but interpreted modulo the + * device queue size when used. + * index <=3D device_curr_frag <=3D driver_curr_frag at all times + * For rx queues, [index, device_curr_frag) contains fragments + * that the interrupt processing needs to handle (owned by driver). + * [device_curr_frag, driver_curr_frag) is the free space in the + * rx queue, waiting for data (owned by device). The driver + * increments driver_curr_frag to indicate to the device that more + * buffers are available. + * If device_curr_frag =3D=3D driver_curr_frag, no more rx buffers are + * available, and the rx DMA engine of the device is halted. + * For tx queues, [index, device_curr_frag) contains fragments + * where tx is done; they need to be freed (owned by driver). + * [device_curr_frag, driver_curr_frag) contains the frames + * that are being transferred (owned by device). The driver + * increments driver_curr_frag to indicate that more tx work + * needs to be done. + */ + u32 index_mgmt_rx; /* real index mgmt rx queue */ + u32 index_mgmt_tx; /* read index mgmt tx queue */ + u32 free_data_rx; /* free pointer data rx queue */ + u32 free_data_tx; /* free pointer data tx queue */ + u32 data_low_tx_full; /* full detected flag */ + + /* frame memory buffers for the device queues */ + struct islpci_membuf mgmt_tx[ISL38XX_CB_MGMT_QSIZE]; + struct islpci_membuf mgmt_rx[ISL38XX_CB_MGMT_QSIZE]; + struct sk_buff *data_low_tx[ISL38XX_CB_TX_QSIZE]; + struct sk_buff *data_low_rx[ISL38XX_CB_RX_QSIZE]; + dma_addr_t pci_map_tx_address[ISL38XX_CB_TX_QSIZE]; + dma_addr_t pci_map_rx_address[ISL38XX_CB_RX_QSIZE]; + + /* driver network interface members */ + struct net_device_stats statistics; + + /* wait for a reset interrupt */ + wait_queue_head_t reset_done; + + /* used by islpci_mgt_transaction */ + struct semaphore mgmt_sem; /* serialize access to mailbox and wqueue */ + struct islpci_mgmtframe *mgmt_received; /* mbox for incoming frame */ + wait_queue_head_t mgmt_wqueue; /* waitqueue for mbox */ + + /* state machine */ + islpci_state_t state; + int state_off; /* enumeration of off-state, if 0 then + * we're not in any off-state */ + + /* WPA stuff */ + int wpa; /* WPA mode enabled */ + struct list_head bss_wpa_list; + int num_bss_wpa; + struct semaphore wpa_sem; + + struct work_struct reset_task; + int reset_task_pending; +} islpci_private; + +static inline islpci_state_t +islpci_get_state(islpci_private *priv) +{ + /* lock */ + return priv->state; + /* unlock */ +} + +islpci_state_t islpci_set_state(islpci_private *priv, islpci_state_t new_s= tate); + +#define ISLPCI_TX_TIMEOUT (2*HZ) + +irqreturn_t islpci_interrupt(int, void *, struct pt_regs *); + +int prism54_post_setup(islpci_private *, int); +int islpci_reset(islpci_private *, int); + +static inline void +islpci_trigger(islpci_private *priv) +{ + isl38xx_trigger_device(islpci_get_state(priv) =3D=3D PRV_STATE_SLEEP, + priv->device_base); +} + +struct net_device_stats *islpci_statistics(struct net_device *); + +int prism54_bring_down(islpci_private *); +int islpci_alloc_memory(islpci_private *); +int islpci_free_memory(islpci_private *); +struct net_device *islpci_setup(struct pci_dev *); +#endif /* _ISLPCI_DEV_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_eth.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_eth.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_eth.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_eth.c 2004-06-= 23 05:30:04.000000000 +0000 @@ -0,0 +1,512 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2004 Aurelien Alleaume + * 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 + * + * 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 "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_eth.h" +#include "islpci_mgt.h" +#include "oid_mgt.h" + +/*************************************************************************= ***** + Network Interface functions +**************************************************************************= ****/ +void +islpci_eth_cleanup_transmit(islpci_private *priv, + isl38xx_control_block *control_block) +{ + struct sk_buff *skb; + u32 index; + + /* compare the control block read pointer with the free pointer */ + while (priv->free_data_tx !=3D + le32_to_cpu(control_block-> + device_curr_frag[ISL38XX_CB_TX_DATA_LQ])) { + /* read the index of the first fragment to be freed */ + index =3D priv->free_data_tx % ISL38XX_CB_TX_QSIZE; + + /* check for holes in the arrays caused by multi fragment frames=20 + * searching for the last fragment of a frame */ + if (priv->pci_map_tx_address[index] !=3D (dma_addr_t) NULL) { + /* entry is the last fragment of a frame + * free the skb structure and unmap pci memory */ + skb =3D priv->data_low_tx[index]; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "cleanup skb %p skb->data %p skb->len %u truesize %u\n ", + skb, skb->data, skb->len, skb->truesize); +#endif + + pci_unmap_single(priv->pdev, + priv->pci_map_tx_address[index], + skb->len, PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); + skb =3D NULL; + } + /* increment the free data low queue pointer */ + priv->free_data_tx++; + } +} + +int +islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D priv->control_block; + u32 index; + dma_addr_t pci_map_address; + int frame_size; + isl38xx_fragment *fragment; + int offset; + struct sk_buff *newskb; + int newskb_offset; + unsigned long flags; + unsigned char wds_mac[6]; + u32 curr_frag; + int err =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_transmit \n"); +#endif + + /* lock the driver code */ + spin_lock_irqsave(&priv->slock, flags); + + /* determine the amount of fragments needed to store the frame */ + + frame_size =3D skb->len < ETH_ZLEN ? ETH_ZLEN : skb->len; + if (init_wds) + frame_size +=3D 6; + + /* check whether the destination queue has enough fragments for the frame= */ + curr_frag =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ]); + if (unlikely(curr_frag - priv->free_data_tx >=3D ISL38XX_CB_TX_QSIZE)) { + printk(KERN_ERR "%s: transmit device queue full when awake\n", + ndev->name); + netif_stop_queue(ndev); + + /* trigger the device */ + isl38xx_w32_flush(priv->device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + err =3D -EBUSY; + goto drop_free; + } + /* Check alignment and WDS frame formatting. The start of the packet shou= ld + * be aligned on a 4-byte boundary. If WDS is enabled add another 6 bytes + * and add WDS address information */ + if (unlikely(((long) skb->data & 0x03) | init_wds)) { + /* get the number of bytes to add and re-allign */ + offset =3D (4 - (long) skb->data) & 0x03; + offset +=3D init_wds ? 6 : 0; + + /* check whether the current skb can be used */ + if (!skb_cloned(skb) && (skb_tailroom(skb) >=3D offset)) { + unsigned char *src =3D skb->data; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "skb offset %i wds %i\n", offset, + init_wds); +#endif + + /* align the buffer on 4-byte boundary */ + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + if (init_wds) { + /* wds requires an additional address field of 6 bytes */ + skb_put(skb, 6); +#ifdef ISLPCI_ETH_DEBUG + printk("islpci_eth_transmit:wds_mac\n"); +#endif + memmove(skb->data + 6, src, skb->len); + memcpy(skb->data, wds_mac, 6); + } else { + memmove(skb->data, src, skb->len); + } + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "memmove %p %p %i \n", skb->data, + src, skb->len); +#endif + } else { + newskb =3D + dev_alloc_skb(init_wds ? skb->len + 6 : skb->len); + newskb_offset =3D (4 - (long) newskb->data) & 0x03; + + /* Check if newskb->data is aligned */ + if (newskb_offset) + skb_reserve(newskb, newskb_offset); + + skb_put(newskb, init_wds ? skb->len + 6 : skb->len); + if (init_wds) { + memcpy(newskb->data + 6, skb->data, skb->len); + memcpy(newskb->data, wds_mac, 6); +#ifdef ISLPCI_ETH_DEBUG + printk("islpci_eth_transmit:wds_mac\n"); +#endif + } else + memcpy(newskb->data, skb->data, skb->len); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "memcpy %p %p %i wds %i\n", + newskb->data, skb->data, skb->len, init_wds); +#endif + + newskb->dev =3D skb->dev; + dev_kfree_skb(skb); + skb =3D newskb; + } + } + /* display the buffer contents for debugging */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_BUFFER_CONTENTS, "\ntx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* map the skb buffer to pci memory for DMA operation */ + pci_map_address =3D pci_map_single(priv->pdev, + (void *) skb->data, skb->len, + PCI_DMA_TODEVICE); + if (unlikely(pci_map_address =3D=3D 0)) { + printk(KERN_WARNING "%s: cannot map buffer to PCI\n", + ndev->name); + + err =3D -EIO; + goto drop_free; + } + /* Place the fragment in the control block structure. */ + index =3D curr_frag % ISL38XX_CB_TX_QSIZE; + fragment =3D &cb->tx_data_low[index]; + + priv->pci_map_tx_address[index] =3D pci_map_address; + /* store the skb address for future freeing */ + priv->data_low_tx[index] =3D skb; + /* set the proper fragment start address and size information */ + fragment->size =3D cpu_to_le16(frame_size); + fragment->flags =3D cpu_to_le16(0); /* set to 1 if more fragments */ + fragment->address =3D cpu_to_le32(pci_map_address); + curr_frag++; + + /* The fragment address in the control block must have been + * written before announcing the frame buffer to device. */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ] =3D cpu_to_le32(curr_frag); + + if (curr_frag - priv->free_data_tx + ISL38XX_MIN_QTHRESHOLD + > ISL38XX_CB_TX_QSIZE) { + /* stop sends from upper layers */ + netif_stop_queue(ndev); + + /* set the full flag for the transmission queue */ + priv->data_low_tx_full =3D 1; + } + + /* trigger the device */ + islpci_trigger(priv); + + /* unlock the driver code */ + spin_unlock_irqrestore(&priv->slock, flags); + + /* set the transmission time */ + ndev->trans_start =3D jiffies; + priv->statistics.tx_packets++; + priv->statistics.tx_bytes +=3D skb->len; + + return 0; + + drop_free: + /* free the skbuf structure before aborting */ + dev_kfree_skb(skb); + skb =3D NULL; + + priv->statistics.tx_dropped++; + spin_unlock_irqrestore(&priv->slock, flags); + return err; +} + +static inline int +islpci_monitor_rx(islpci_private *priv, struct sk_buff **skb) +{ + /* The card reports full 802.11 packets but with a 20 bytes + * header and without the FCS. But there a is a bit that + * indicates if the packet is corrupted :-) */ + struct rfmon_header *hdr =3D (struct rfmon_header *) (*skb)->data; + if (hdr->flags & 0x01) + /* This one is bad. Drop it ! */ + return -1; + if (priv->ndev->type =3D=3D ARPHRD_IEEE80211_PRISM) { + struct avs_80211_1_header *avs; + /* extract the relevant data from the header */ + u32 clock =3D le32_to_cpu(hdr->clock); + u8 rate =3D hdr->rate; + u16 freq =3D le16_to_cpu(hdr->freq); + u8 rssi =3D hdr->rssi; + + skb_pull(*skb, sizeof (struct rfmon_header)); + + if (skb_headroom(*skb) < sizeof (struct avs_80211_1_header)) { + struct sk_buff *newskb =3D skb_copy_expand(*skb, + sizeof (struct + avs_80211_1_header), + 0, GFP_ATOMIC); + if (newskb) { + dev_kfree_skb_irq(*skb); + *skb =3D newskb; + } else + return -1; + /* This behavior is not very subtile... */ + } + + /* make room for the new header and fill it. */ + avs =3D + (struct avs_80211_1_header *) skb_push(*skb, + sizeof (struct + avs_80211_1_header)); + =09 + avs->version =3D cpu_to_be32(P80211CAPTURE_VERSION); + avs->length =3D cpu_to_be32(sizeof (struct avs_80211_1_header)); + avs->mactime =3D cpu_to_be64(le64_to_cpu(clock)); + avs->hosttime =3D cpu_to_be64(jiffies); + avs->phytype =3D cpu_to_be32(6); /*OFDM: 6 for (g), 8 for (a) */ + avs->channel =3D cpu_to_be32(channel_of_freq(freq)); + avs->datarate =3D cpu_to_be32(rate * 5); + avs->antenna =3D cpu_to_be32(0); /*unknown */ + avs->priority =3D cpu_to_be32(0); /*unknown */ + avs->ssi_type =3D cpu_to_be32(3); /*2: dBm, 3: raw RSSI */ + avs->ssi_signal =3D cpu_to_be32(rssi & 0x7f); + avs->ssi_noise =3D cpu_to_be32(priv->local_iwstatistics.qual.noise); /*b= etter than 'undefined', I assume */ + avs->preamble =3D cpu_to_be32(0); /*unknown */ + avs->encoding =3D cpu_to_be32(0); /*unknown */ + } else + skb_pull(*skb, sizeof (struct rfmon_header)); + + (*skb)->protocol =3D htons(ETH_P_802_2); + (*skb)->mac.raw =3D (*skb)->data; + (*skb)->pkt_type =3D PACKET_OTHERHOST; + + return 0; +} + +int +islpci_eth_receive(islpci_private *priv) +{ + struct net_device *ndev =3D priv->ndev; + isl38xx_control_block *control_block =3D priv->control_block; + struct sk_buff *skb; + u16 size; + u32 index, offset; + unsigned char *src; + int discard =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_receive \n"); +#endif + + /* the device has written an Ethernet frame in the data area + * of the sk_buff without updating the structure, do it now */ + index =3D priv->free_data_rx % ISL38XX_CB_RX_QSIZE; + size =3D le16_to_cpu(control_block->rx_data_low[index].size); + skb =3D priv->data_low_rx[index]; + offset =3D ((unsigned long) + le32_to_cpu(control_block->rx_data_low[index].address) - + (unsigned long) skb->data) & 3; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "frq->addr %x skb->data %p skb->len %u offset %u truesize %u\n ", + control_block->rx_data_low[priv->free_data_rx].address, skb->data, + skb->len, offset, skb->truesize); +#endif + + /* delete the streaming DMA mapping before processing the skb */ + pci_unmap_single(priv->pdev, + priv->pci_map_rx_address[index], + MAX_FRAGMENT_SIZE_RX + 2, PCI_DMA_FROMDEVICE); + + /* update the skb structure and allign the buffer */ + skb_put(skb, size); + if (offset) { + /* shift the buffer allocation offset bytes to get the right frame */ + skb_pull(skb, 2); + skb_put(skb, 2); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + /* display the buffer contents for debugging */ + DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* check whether WDS is enabled and whether the data frame is a WDS frame= */ + + if (init_wds) { + /* WDS enabled, check for the wds address on the first 6 bytes of the bu= ffer */ + src =3D skb->data + 6; + memmove(skb->data, src, skb->len - 6); + skb_trim(skb, skb->len - 6); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Fragment size %i in skb at %p\n", size, skb); + DEBUG(SHOW_TRACING, "Skb data at %p, length %i\n", skb->data, skb->len); + + /* display the buffer contents for debugging */ + DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* do some additional sk_buff and network layer parameters */ + skb->dev =3D ndev; + + /* take care of monitor mode and spy monitoring. */ + if (unlikely(priv->iw_mode =3D=3D IW_MODE_MONITOR)) + discard =3D islpci_monitor_rx(priv, &skb); + else { + if (unlikely(skb->data[2 * ETH_ALEN] =3D=3D 0)) { + /* The packet has a rx_annex. Read it for spy monitoring, Then + * remove it, while keeping the 2 leading MAC addr. + */ + struct iw_quality wstats; + struct rx_annex_header *annex =3D + (struct rx_annex_header *) skb->data; + wstats.level =3D annex->rfmon.rssi; + /* The noise value can be a bit outdated if nobody's=20 + * reading wireless stats... */ + wstats.noise =3D priv->local_iwstatistics.qual.noise; + wstats.qual =3D wstats.level - wstats.noise; + wstats.updated =3D 0x07; + /* Update spy records */ + wireless_spy_update(ndev, annex->addr2, &wstats); + + memcpy(skb->data + sizeof (struct rfmon_header), + skb->data, 2 * ETH_ALEN); + skb_pull(skb, sizeof (struct rfmon_header)); + } + skb->protocol =3D eth_type_trans(skb, ndev); + } + skb->ip_summed =3D CHECKSUM_NONE; + priv->statistics.rx_packets++; + priv->statistics.rx_bytes +=3D size; + + /* deliver the skb to the network layer */ +#ifdef ISLPCI_ETH_DEBUG + printk + ("islpci_eth_receive:netif_rx %2.2X %2.2X %2.2X %2.2X %2.2X %2.2X\n", + skb->data[0], skb->data[1], skb->data[2], skb->data[3], + skb->data[4], skb->data[5]); +#endif + if (unlikely(discard)) { + dev_kfree_skb_irq(skb); + skb =3D NULL; + } else + netif_rx(skb); + + /* increment the read index for the rx data low queue */ + priv->free_data_rx++; + + /* add one or more sk_buff structures */ + while (index =3D + le32_to_cpu(control_block-> + driver_curr_frag[ISL38XX_CB_RX_DATA_LQ]), + index - priv->free_data_rx < ISL38XX_CB_RX_QSIZE) { + /* allocate an sk_buff for received data frames storage + * include any required allignment operations */ + skb =3D dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2); + if (unlikely(skb =3D=3D NULL)) { + /* error allocating an sk_buff structure elements */ + DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n"); + break; + } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + /* store the new skb structure pointer */ + index =3D index % ISL38XX_CB_RX_QSIZE; + priv->data_low_rx[index] =3D skb; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "new alloc skb %p skb->data %p skb->len %u index %u truesize %u\n = ", + skb, skb->data, skb->len, index, skb->truesize); +#endif + + /* set the streaming DMA mapping for proper PCI bus operation */ + priv->pci_map_rx_address[index] =3D + pci_map_single(priv->pdev, (void *) skb->data, + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + if (unlikely(priv->pci_map_rx_address[index] =3D=3D (dma_addr_t) NULL)) { + /* error mapping the buffer to device accessable memory address */ + DEBUG(SHOW_ERROR_MESSAGES, + "Error mapping DMA address\n"); + + /* free the skbuf structure before aborting */ + dev_kfree_skb_irq((struct sk_buff *) skb); + skb =3D NULL; + break; + } + /* update the fragment address */ + control_block->rx_data_low[index].address =3D cpu_to_le32((u32) + priv-> + pci_map_rx_address + [index]); + wmb(); + + /* increment the driver read pointer */ + add_le32p((u32 *) &control_block-> + driver_curr_frag[ISL38XX_CB_RX_DATA_LQ], 1); + } + + /* trigger the device */ + islpci_trigger(priv); + + return 0; +} + +void +islpci_do_reset_and_wake(void *data) +{ + islpci_private *priv =3D (islpci_private *) data; + islpci_reset(priv, 1); + netif_wake_queue(priv->ndev); + priv->reset_task_pending =3D 0; +} + +void +islpci_eth_tx_timeout(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct net_device_stats *statistics =3D &priv->statistics; + + /* increment the transmit error counter */ + statistics->tx_errors++; + + if (!priv->reset_task_pending) { + priv->reset_task_pending =3D 1; + netif_stop_queue(ndev); + schedule_work(&priv->reset_task); + } + + return; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_eth.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_eth.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_eth.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_eth.h 2004-06-= 23 05:30:04.000000000 +0000 @@ -0,0 +1,73 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * + * 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 + * + * 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 _ISLPCI_ETH_H +#define _ISLPCI_ETH_H + +#include "isl_38xx.h" +#include "islpci_dev.h" + +struct rfmon_header { + u16 unk0; /* =3D 0x0000 */ + u16 length; /* =3D 0x1400 */ + u32 clock; /* 1MHz clock */ + u8 flags; + u8 unk1; + u8 rate; + u8 unk2; + u16 freq; + u16 unk3; + u8 rssi; + u8 padding[3]; +} __attribute__ ((packed)); + +struct rx_annex_header { + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + struct rfmon_header rfmon; +} __attribute__ ((packed)); + +/* wlan-ng (and hopefully others) AVS header, version one. Fields in + * network byte order. */ +#define P80211CAPTURE_VERSION 0x80211001 + +struct avs_80211_1_header { + uint32_t version; + uint32_t length; + uint64_t mactime; + uint64_t hosttime; + uint32_t phytype; + uint32_t channel; + uint32_t datarate; + uint32_t antenna; + uint32_t priority; + uint32_t ssi_type; + int32_t ssi_signal; + int32_t ssi_noise; + uint32_t preamble; + uint32_t encoding; +}; + +void islpci_eth_cleanup_transmit(islpci_private *, isl38xx_control_block *= ); +int islpci_eth_transmit(struct sk_buff *, struct net_device *); +int islpci_eth_receive(islpci_private *); +void islpci_eth_tx_timeout(struct net_device *); +void islpci_do_reset_and_wake(void *data); + +#endif /* _ISL_GEN_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_hotplug.c linux-2.4.26-prism54/drivers/net/wireless/prism54/i= slpci_hotplug.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_hotplug.c 1970-01-01 0= 0:00:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_hotplug.c 2004= -06-23 05:30:04.000000000 +0000 @@ -0,0 +1,437 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Herbert Valerio Riedel + * + * 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 + * + * 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 /* For __init, __exit */ + +#include "prismcompat.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" /* for pc_debug */ +#include "isl_oid.h" + +#define DRV_NAME "prism54" +#define DRV_VERSION "1.2" + +MODULE_AUTHOR("[Intersil] R.Bastings and W.Termorshuizen, The prism54.org = Development Team "); +MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter"); +MODULE_LICENSE("GPL"); + +/* In this order: vendor, device, subvendor, subdevice, class, class_mask, + * driver_data=20 + * Note: for driver_data we put the device's name=20 + * If you have an update for this please contact prism54-devel@prism54.org= =20 + * The latest list can be found at http://prism54.org/supported_cards.php = */ +static const struct pci_device_id prism54_id_tbl[] =3D { + { + PCIVENDOR_3COM, PCIDEVICE_3COM6001, + PCIVENDOR_3COM, PCIDEVICE_3COM6001, + 0, 0, + (unsigned long) "3COM 3CRWE154G72 Wireless LAN adapter"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_DLINK, 0x3202UL,=20 + 0, 0, + (unsigned long) "D-Link Air Plus Xtreme G A1 - DWL-g650 A1"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_IODATA, 0xd019UL,=20 + 0, 0, + (unsigned long) "I-O Data WN-G54/CB - WN-G54/CB"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_NETGEAR, 0x4800UL, + 0, 0, + (unsigned long) "Netgear WG511"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0020UL, + 0, 0, + (unsigned long) "PLANEX GW-DS54G"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0x2802UL, + 0, 0, + (unsigned long) "EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card - SMC2802= W"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0x2835UL, + 0, 0, + (unsigned long) "EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Adapter - = SMC2835W"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_INTERSIL, 0x0000UL, /* This was probably a bogus reading... */ + 0, 0, + (unsigned long) "SparkLAN WL-850F"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0014UL, + 0, 0, + (unsigned long) "I4 Z-Com XG-600"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0020UL, + 0, 0, + (unsigned long) "I4 Z-Com XG-900/PLANEX GW-DS54G"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_ACCTON, 0xee03UL, + 0, 0, + (unsigned long) "SMC 2802Wv2"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0xa835UL, + 0, 0, + (unsigned long) "SMC 2835Wv2"}, + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + (unsigned long) "Intersil PRISM Indigo Wireless LAN adapter"}, + { /* Default */ + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + (unsigned long) "Intersil PRISM Duette/Prism GT Wireless LAN adapter"}, + {0,} +}; + +/* register the device with the Hotplug facilities of the kernel */ +MODULE_DEVICE_TABLE(pci, prism54_id_tbl); + +static int prism54_probe(struct pci_dev *, const struct pci_device_id *); +static void prism54_remove(struct pci_dev *); +static int prism54_suspend(struct pci_dev *, u32 state); +static int prism54_resume(struct pci_dev *); + +static struct pci_driver prism54_driver =3D { + .name =3D DRV_NAME, + .id_table =3D prism54_id_tbl, + .probe =3D prism54_probe, + .remove =3D prism54_remove, + .suspend =3D prism54_suspend, + .resume =3D prism54_resume, + /* .enable_wake ; we don't support this yet */ +}; + +static void +prism54_get_card_model(struct net_device *ndev) +{ + islpci_private *priv; + char *modelp; + + priv =3D netdev_priv(ndev); + switch (priv->pdev->subsystem_device) { + case PCIDEVICE_ISL3877: + modelp =3D "PRISM Indigo"; + break; + case PCIDEVICE_3COM6001: + modelp =3D "3COM 3CRWE154G72"; + break; + case 0x3202UL: + modelp =3D "D-Link DWL-g650 A1"; + break; + case 0xd019UL: + modelp =3D "WN-G54/CB"; + break; + case 0x4800UL: + modelp =3D "Netgear WG511"; + break; + case 0x2802UL: + modelp =3D "SMC2802W"; + break; + case 0xee03UL: + modelp =3D "SMC2802W V2"; + break; + case 0x2835UL: + modelp =3D "SMC2835W"; + break; + case 0xa835UL: + modelp =3D "SMC2835W V2"; + break; + /* Let's leave this one out for now since it seems bogus/wrong=20 + * Even if the manufacturer did use 0x0000UL it may not be correct + * by their part, therefore deserving no name ;) */ + /* case 0x0000UL:=20 + * modelp =3D "SparkLAN WL-850F"; + * break;*/ + + /* We have two reported for the one below :( */ + case 0x0014UL: + modelp =3D "XG-600"; + break; + case 0x0020UL: + modelp =3D "XG-900/GW-DS54G"; + break; +/* Default it */ +/* + case PCIDEVICE_ISL3890: + modelp =3D "PRISM Duette/GT"; + break; +*/ + default: + modelp =3D "PRISM Duette/GT"; + } + printk(KERN_DEBUG "%s: %s driver detected card model: %s\n", + ndev->name, DRV_NAME, modelp); + return; +} + +/*************************************************************************= ***** + Module initialization functions +**************************************************************************= ****/ + +int +prism54_probe(struct pci_dev *pdev, const struct pci_device_id *id) +{ + struct net_device *ndev; + u8 latency_tmr; + u32 mem_addr; + islpci_private *priv; + int rvalue; + + /* TRACE(DRV_NAME); */ +=09 +=09 + /* Enable the pci device */ + if (pci_enable_device(pdev)) { + printk(KERN_ERR "%s: pci_enable_device() failed.\n", DRV_NAME); + return -ENODEV; + } + + /* check whether the latency timer is set correctly */ + pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency_tmr); +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "latency timer: %x\n", latency_tmr); +#endif + if (latency_tmr < PCIDEVICE_LATENCY_TIMER_MIN) { + /* set the latency timer */ + pci_write_config_byte(pdev, PCI_LATENCY_TIMER, + PCIDEVICE_LATENCY_TIMER_VAL); + } + + /* enable PCI DMA */ + if (pci_set_dma_mask(pdev, 0xffffffff)) { + printk(KERN_ERR "%s: 32-bit PCI DMA not supported", DRV_NAME); + goto do_pci_disable_device; + } + + /* 0x40 is the programmable timer to configure the response timeout (TRDY= _TIMEOUT) + * 0x41 is the programmable timer to configure the retry timeout (RETRY_T= IMEOUT) + * The RETRY_TIMEOUT is used to set the number of retries that the core,= as a + * Master, will perform before abandoning a cycle. The default value for + * RETRY_TIMEOUT is 0x80, which far exceeds the PCI 2.1 requirement for = new + * devices. A write of zero to the RETRY_TIMEOUT register disables this + * function to allow use with any non-compliant legacy devices that may + * execute more retries. + * + * Writing zero to both these two registers will disable both timeouts a= nd + * *can* solve problems caused by devices that are slow to respond. + */ + pci_write_config_byte(pdev, 0x40, 0); + pci_write_config_byte(pdev, 0x41, 0); + + /* request the pci device I/O regions */ + rvalue =3D pci_request_regions(pdev, DRV_NAME); + if (rvalue) { + printk(KERN_ERR "%s: pci_request_regions failure (rc=3D%d)\n", + DRV_NAME, rvalue); + goto do_pci_disable_device; + } + + /* check if the memory window is indeed set */ + rvalue =3D pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &mem_addr); + if (rvalue || !mem_addr) { + printk(KERN_ERR "%s: PCI device memory region not configured; fix your B= IOS or CardBus bridge/drivers\n", + DRV_NAME); + goto do_pci_disable_device; + } + + /* enable PCI bus-mastering */ + DEBUG(SHOW_TRACING, "%s: pci_set_master(pdev)\n", DRV_NAME); + pci_set_master(pdev); + + /* setup the network device interface and its structure */ + if (!(ndev =3D islpci_setup(pdev))) { + /* error configuring the driver as a network device */ + printk(KERN_ERR "%s: could not configure network device\n", + DRV_NAME); + goto do_pci_release_regions; + } + + priv =3D netdev_priv(ndev); + islpci_set_state(priv, PRV_STATE_PREBOOT); /* we are attempting to boot */ + + /* card is in unknown state yet, might have some interrupts pending */ + isl38xx_disable_interrupts(priv->device_base); + + /* request for the interrupt before uploading the firmware */ + rvalue =3D request_irq(pdev->irq, &islpci_interrupt, + SA_SHIRQ, ndev->name, priv); + + if (rvalue) { + /* error, could not hook the handler to the irq */ + printk(KERN_ERR "%s: could not install IRQ handler\n", + ndev->name); + goto do_unregister_netdev; + } + + /* 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); + free_netdev(ndev); + priv =3D 0; + do_pci_release_regions: + pci_release_regions(pdev); + do_pci_disable_device: + pci_disable_device(pdev); + return -EIO; +} + +/* set by cleanup_module */ +static volatile int __in_cleanup_module =3D 0; + +/* this one removes one(!!) instance only */ +void +prism54_remove(struct pci_dev *pdev) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + if (!__in_cleanup_module) { + printk(KERN_DEBUG "%s: hot unplug detected\n", ndev->name); + islpci_set_state(priv, PRV_STATE_OFF); + } + + printk(KERN_DEBUG "%s: removing device\n", ndev->name); + + unregister_netdev(ndev); + + /* free the interrupt request */ + + if (islpci_get_state(priv) !=3D PRV_STATE_OFF) { + isl38xx_disable_interrupts(priv->device_base); + islpci_set_state(priv, PRV_STATE_OFF); + /* This bellow causes a lockup at rmmod time. It might be + * because some interrupts still linger after rmmod time,=20 + * see bug #17 */ + /* pci_set_power_state(pdev, 3);*/ /* try to power-off */ + } + + free_irq(pdev->irq, priv); + + /* free the PCI memory and unmap the remapped page */ + islpci_free_memory(priv); + + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + + pci_release_regions(pdev); + + pci_disable_device(pdev); +} + +int +prism54_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + printk(KERN_NOTICE "%s: got suspend request (state %d)\n", + ndev->name, state); + + pci_save_state(pdev, priv->pci_state); + + /* tell the device not to trigger interrupts for now... */ + isl38xx_disable_interrupts(priv->device_base); + + /* from now on assume the hardware was already powered down + and don't touch it anymore */ + islpci_set_state(priv, PRV_STATE_OFF); + + netif_stop_queue(ndev); + netif_device_detach(ndev); + + return 0; +} + +int +prism54_resume(struct pci_dev *pdev) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + printk(KERN_NOTICE "%s: got resume request\n", ndev->name); + + pci_restore_state(pdev, priv->pci_state); + + /* alright let's go into the PREBOOT state */ + islpci_reset(priv, 1); + + netif_device_attach(ndev); + netif_start_queue(ndev); + + return 0; +} + +static int __init +prism54_module_init(void) +{ + printk(KERN_INFO "Loaded %s driver, version %s\n", + DRV_NAME, DRV_VERSION); + + __bug_on_wrong_struct_sizes (); + + return pci_module_init(&prism54_driver); +} + +/* by the time prism54_module_exit() terminates, as a postcondition + * all instances will have been destroyed by calls to + * prism54_remove() */ +static void __exit +prism54_module_exit(void) +{ + __in_cleanup_module =3D 1; + + pci_unregister_driver(&prism54_driver); + + printk(KERN_INFO "Unloaded %s driver\n", DRV_NAME); + + __in_cleanup_module =3D 0; +} + +/* register entry points */ +module_init(prism54_module_init); +module_exit(prism54_module_exit); +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_mgt.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_mgt.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_mgt.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_mgt.c 2004-06-= 23 05:30:04.000000000 +0000 @@ -0,0 +1,508 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright 2004 Jens Maurer + * + * 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 + * + * 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 "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_mgt.h" +#include "isl_oid.h" /* additional types and defs for isl38xx fw */ +#include "isl_ioctl.h" + +#include + +/*************************************************************************= ***** + Global variable definition section +**************************************************************************= ****/ +int pc_debug =3D VERBOSE; +module_param(pc_debug, int, 0); + +/*************************************************************************= ***** + Driver general functions +**************************************************************************= ****/ +void +display_buffer(char *buffer, int length) +{ + if ((pc_debug & SHOW_BUFFER_CONTENTS) =3D=3D 0) + return; + + while (length > 0) { + printk("[%02x]", *buffer & 255); + length--; + buffer++; + } + + printk("\n"); +} + +/*************************************************************************= **** + Queue handling for management frames +**************************************************************************= ****/ + +/* + * Helper function to create a PIMFOR management frame header. + */ +static void +pimfor_encode_header(int operation, u32 oid, u32 length, pimfor_header_t *= h) +{ + h->version =3D PIMFOR_VERSION; + h->operation =3D operation; + h->device_id =3D PIMFOR_DEV_ID_MHLI_MIB; + h->flags =3D 0; + h->oid =3D cpu_to_be32(oid); + h->length =3D cpu_to_be32(length); +} + +/* + * Helper function to analyze a PIMFOR management frame header. + */ +static pimfor_header_t * +pimfor_decode_header(void *data, int len) +{ + pimfor_header_t *h =3D data; + + while ((void *) h < data + len) { + if (h->flags & PIMFOR_FLAG_LITTLE_ENDIAN) { + le32_to_cpus(&h->oid); + le32_to_cpus(&h->length); + } else { + be32_to_cpus(&h->oid); + be32_to_cpus(&h->length); + } + if (h->oid !=3D OID_INL_TUNNEL) + return h; + h++; + } + return NULL; +} + +/* + * Fill the receive queue for management frames with fresh buffers. + */ +int +islpci_mgmt_rx_fill(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + u32 curr =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ]); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgmt_rx_fill \n"); +#endif + + while (curr - priv->index_mgmt_rx < ISL38XX_CB_MGMT_QSIZE) { + u32 index =3D curr % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_rx[index]; + isl38xx_fragment *frag =3D &cb->rx_data_mgmt[index]; + + if (buf->mem =3D=3D NULL) { + buf->mem =3D kmalloc(MGMT_FRAME_SIZE, GFP_ATOMIC); + if (!buf->mem) { + printk(KERN_WARNING + "Error allocating management frame.\n"); + return -ENOMEM; + } + buf->size =3D MGMT_FRAME_SIZE; + } + if (buf->pci_addr =3D=3D 0) { + buf->pci_addr =3D pci_map_single(priv->pdev, buf->mem, + MGMT_FRAME_SIZE, + PCI_DMA_FROMDEVICE); + if (!buf->pci_addr) { + printk(KERN_WARNING + "Failed to make memory DMA'able\n."); + return -ENOMEM; + } + } + + /* be safe: always reset control block information */ + frag->size =3D cpu_to_le16(MGMT_FRAME_SIZE); + frag->flags =3D 0; + frag->address =3D cpu_to_le32(buf->pci_addr); + curr++; + + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] =3D cpu_to_le32(curr); + } + return 0; +} + +/* + * Create and transmit a management frame using "operation" and "oid", + * with arguments data/length. + * We either return an error and free the frame, or we return 0 and + * islpci_mgt_cleanup_transmit() frees the frame in the tx-done + * interrupt. + */ +static int +islpci_mgt_transmit(struct net_device *ndev, int operation, unsigned long = oid, + void *data, int length) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D + (isl38xx_control_block *) priv->control_block; + void *p; + int err =3D -EINVAL; + unsigned long flags; + isl38xx_fragment *frag; + struct islpci_membuf buf; + u32 curr_frag; + int index; + int frag_len =3D length + PIMFOR_HEADER_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_transmit\n"); +#endif + + if (frag_len > MGMT_FRAME_SIZE) { + printk(KERN_DEBUG "%s: mgmt frame too large %d\n", + ndev->name, frag_len); + goto error; + } + + err =3D -ENOMEM; + p =3D buf.mem =3D kmalloc(frag_len, GFP_KERNEL); + if (!buf.mem) { + printk(KERN_DEBUG "%s: cannot allocate mgmt frame\n", + ndev->name); + goto error; + } + buf.size =3D frag_len; + + /* create the header directly in the fragment data area */ + pimfor_encode_header(operation, oid, length, (pimfor_header_t *) p); + p +=3D PIMFOR_HEADER_SIZE; + + if (data) + memcpy(p, data, length); + else + memset(p, 0, length); + +#if VERBOSE > SHOW_ERROR_MESSAGES + { + pimfor_header_t *h =3D buf.mem; + DEBUG(SHOW_PIMFOR_FRAMES, + "PIMFOR: op %i, oid 0x%08lx, device %i, flags 0x%x length 0x%x \n", + h->operation, oid, h->device_id, h->flags, length); + + /* display the buffer contents for debugging */ + display_buffer((char *) h, sizeof (pimfor_header_t)); + display_buffer(p, length); + } +#endif + + err =3D -ENOMEM; + buf.pci_addr =3D pci_map_single(priv->pdev, buf.mem, frag_len, + PCI_DMA_TODEVICE); + if (!buf.pci_addr) { + printk(KERN_WARNING "%s: cannot map PCI memory for mgmt\n", + ndev->name); + goto error_free; + } + + /* Protect the control block modifications against interrupts. */ + spin_lock_irqsave(&priv->slock, flags); + curr_frag =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ]); + if (curr_frag - priv->index_mgmt_tx >=3D ISL38XX_CB_MGMT_QSIZE) { + printk(KERN_WARNING "%s: mgmt tx queue is still full\n", + ndev->name); + goto error_unlock; + } + + /* commit the frame to the tx device queue */ + index =3D curr_frag % ISL38XX_CB_MGMT_QSIZE; + priv->mgmt_tx[index] =3D buf; + frag =3D &cb->tx_data_mgmt[index]; + frag->size =3D cpu_to_le16(frag_len); + frag->flags =3D 0; /* for any other than the last fragment, set to 1 */ + frag->address =3D cpu_to_le32(buf.pci_addr); + + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ] =3D cpu_to_le32(curr_frag + 1); + spin_unlock_irqrestore(&priv->slock, flags); + + /* trigger the device */ + islpci_trigger(priv); + return 0; + + error_unlock: + spin_unlock_irqrestore(&priv->slock, flags); + error_free: + kfree(buf.mem); + error: + return err; +} + +/* + * Receive a management frame from the device. + * This can be an arbitrary number of traps, and at most one response + * frame for a previous request sent via islpci_mgt_transmit(). + */ +int +islpci_mgt_receive(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D + (isl38xx_control_block *) priv->control_block; + u32 curr_frag; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive \n"); +#endif + + /* Only once per interrupt, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * frames come in faster than we can process them. */ + curr_frag =3D le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_RX_MGMTQ]); + barrier(); + + for (; priv->index_mgmt_rx < curr_frag; priv->index_mgmt_rx++) { + pimfor_header_t *header; + u32 index =3D priv->index_mgmt_rx % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_rx[index]; + u16 frag_len; + int size; + struct islpci_mgmtframe *frame; + + /* I have no idea (and no documentation) if flags !=3D 0 + * is possible. Drop the frame, reuse the buffer. */ + if (le16_to_cpu(cb->rx_data_mgmt[index].flags) !=3D 0) { + printk(KERN_WARNING "%s: unknown flags 0x%04x\n", + ndev->name, + le16_to_cpu(cb->rx_data_mgmt[index].flags)); + continue; + } + + /* The device only returns the size of the header(s) here. */ + frag_len =3D le16_to_cpu(cb->rx_data_mgmt[index].size); + + /* + * We appear to have no way to tell the device the + * size of a receive buffer. Thus, if this check + * triggers, we likely have kernel heap corruption. */ + if (frag_len > MGMT_FRAME_SIZE) { + printk(KERN_WARNING + "%s: Bogus packet size of %d (%#x).\n", + ndev->name, frag_len, frag_len); + frag_len =3D MGMT_FRAME_SIZE; + } + + /* Ensure the results of device DMA are visible to the CPU. */ + pci_dma_sync_single(priv->pdev, buf->pci_addr, + buf->size, PCI_DMA_FROMDEVICE); + + /* Perform endianess conversion for PIMFOR header in-place. */ + header =3D pimfor_decode_header(buf->mem, frag_len); + if (!header) { + printk(KERN_WARNING "%s: no PIMFOR header found\n", + ndev->name); + continue; + } + + /* The device ID from the PIMFOR packet received from + * the MVC is always 0. We forward a sensible device_id. + * Not that anyone upstream would care... */ + header->device_id =3D priv->ndev->ifindex; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_PIMFOR_FRAMES, + "PIMFOR: op %i, oid 0x%08x, device %i, flags 0x%x length 0x%x \n", + header->operation, header->oid, header->device_id, + header->flags, header->length); + + /* display the buffer contents for debugging */ + display_buffer((char *) header, PIMFOR_HEADER_SIZE); + display_buffer((char *) header + PIMFOR_HEADER_SIZE, + header->length); +#endif + + /* nobody sends these */ + if (header->flags & PIMFOR_FLAG_APPLIC_ORIGIN) { + printk(KERN_DEBUG + "%s: errant PIMFOR application frame\n", + ndev->name); + continue; + } + + /* Determine frame size, skipping OID_INL_TUNNEL headers. */ + size =3D PIMFOR_HEADER_SIZE + header->length; + frame =3D kmalloc(sizeof (struct islpci_mgmtframe) + size, + GFP_ATOMIC); + if (!frame) { + printk(KERN_WARNING + "%s: Out of memory, cannot handle oid 0x%08x\n", + ndev->name, header->oid); + continue; + } + frame->ndev =3D ndev; + memcpy(&frame->buf, header, size); + frame->header =3D (pimfor_header_t *) frame->buf; + frame->data =3D frame->buf + PIMFOR_HEADER_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_PIMFOR_FRAMES, + "frame: header: %p, data: %p, size: %d\n", + frame->header, frame->data, size); +#endif + + if (header->operation =3D=3D PIMFOR_OP_TRAP) { +#if VERBOSE > SHOW_ERROR_MESSAGES + printk(KERN_DEBUG + "TRAP: oid 0x%x, device %i, flags 0x%x length %i\n", + header->oid, header->device_id, header->flags, + header->length); +#endif + + /* Create work to handle trap out of interrupt + * context. */ + INIT_WORK(&frame->ws, prism54_process_trap, frame); + schedule_work(&frame->ws); + + } else { + /* Signal the one waiting process that a response + * has been received. */ + if ((frame =3D xchg(&priv->mgmt_received, frame)) !=3D NULL) { + printk(KERN_WARNING + "%s: mgmt response not collected\n", + ndev->name); + kfree(frame); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Wake up Mgmt Queue\n"); +#endif + wake_up(&priv->mgmt_wqueue); + } + + } + + return 0; +} + +/* + * Cleanup the transmit queue by freeing all frames handled by the device. + */ +void +islpci_mgt_cleanup_transmit(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + u32 curr_frag; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_cleanup_transmit\n"); +#endif + + /* Only once per cleanup, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * the device became confused, incrementing device_curr_frag + * rapidly. */ + curr_frag =3D le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_TX_MGMTQ]); + barrier(); + + for (; priv->index_mgmt_tx < curr_frag; priv->index_mgmt_tx++) { + int index =3D priv->index_mgmt_tx % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_tx[index]; + pci_unmap_single(priv->pdev, buf->pci_addr, buf->size, + PCI_DMA_TODEVICE); + buf->pci_addr =3D 0; + kfree(buf->mem); + buf->mem =3D NULL; + buf->size =3D 0; + } +} + +/* + * Perform one request-response transaction to the device. + */ +int +islpci_mgt_transaction(struct net_device *ndev, + int operation, unsigned long oid, + void *senddata, int sendlen, + struct islpci_mgmtframe **recvframe) +{ + islpci_private *priv =3D netdev_priv(ndev); + const long wait_cycle_jiffies =3D (ISL38XX_WAIT_CYCLE * 10 * HZ) / 1000; + long timeout_left =3D ISL38XX_MAX_WAIT_CYCLES * wait_cycle_jiffies; + int err; + DEFINE_WAIT(wait); + + if (down_interruptible(&priv->mgmt_sem)) + return -ERESTARTSYS; + + prepare_to_wait(&priv->mgmt_wqueue, &wait, TASK_UNINTERRUPTIBLE); + err =3D islpci_mgt_transmit(ndev, operation, oid, senddata, sendlen); + if (err) + goto out; + + err =3D -ETIMEDOUT; + while (timeout_left > 0) { + int timeleft; + struct islpci_mgmtframe *frame; + + timeleft =3D schedule_timeout(wait_cycle_jiffies); + frame =3D xchg(&priv->mgmt_received, NULL); + if (frame) { + if (frame->header->oid =3D=3D oid) { + *recvframe =3D frame; + err =3D 0; + goto out; + } else { + printk(KERN_DEBUG + "%s: expecting oid 0x%x, received 0x%x.\n", + ndev->name, (unsigned int) oid, + frame->header->oid); + kfree(frame); + frame =3D NULL; + } + } + if (timeleft =3D=3D 0) { + printk(KERN_DEBUG + "%s: timeout waiting for mgmt response %lu, " + "triggering device\n", + ndev->name, timeout_left); + islpci_trigger(priv); + } + timeout_left +=3D timeleft - wait_cycle_jiffies; + } + printk(KERN_WARNING "%s: timeout waiting for mgmt response\n", + ndev->name); + + /* TODO: we should reset the device here */ =20 + out: + finish_wait(&priv->mgmt_wqueue, &wait); + up(&priv->mgmt_sem); + return err; +} + diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_mgt.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_mgt.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_mgt.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_mgt.h 2004-06-= 23 05:30:04.000000000 +0000 @@ -0,0 +1,159 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Luis R. Rodriguez + * + * 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 + * + * 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 _ISLPCI_MGT_H +#define _ISLPCI_MGT_H + +#include +#include + +/* + * Function definitions + */ + +#define K_DEBUG(f, m, args...) do { if(f & m) printk(KERN_DEBUG args); } w= hile(0) +#define DEBUG(f, args...) K_DEBUG(f, pc_debug, args) + +#define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> " __FUNCT= ION__ "()\n", devname) + +extern int pc_debug; +#define init_wds 0 /* help compiler optimize away dead code */ + + +/* 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 PCIDEVICE_ISL3877 0x3877UL +#define PCIDEVICE_ISL3890 0x3890UL +#define PCIDEVICE_3COM6001 0x6001UL +#define PCIDEVICE_LATENCY_TIMER_MIN 0x40 +#define PCIDEVICE_LATENCY_TIMER_VAL 0x50 + +/* Debugging verbose definitions */ +#define SHOW_NOTHING 0x00 /* overrules everythi= ng */ +#define SHOW_ANYTHING 0xFF +#define SHOW_ERROR_MESSAGES 0x01 +#define SHOW_TRAPS 0x02 +#define SHOW_FUNCTION_CALLS 0x04 +#define SHOW_TRACING 0x08 +#define SHOW_QUEUE_INDEXES 0x10 +#define SHOW_PIMFOR_FRAMES 0x20 +#define SHOW_BUFFER_CONTENTS 0x40 +#define VERBOSE 0x01 + +/* Default card definitions */ +#define CARD_DEFAULT_CHANNEL 6 +#define CARD_DEFAULT_MODE INL_MODE_CLIENT +#define CARD_DEFAULT_IW_MODE IW_MODE_INFRA +#define CARD_DEFAULT_BSSTYPE DOT11_BSSTYPE_INFRA +#define CARD_DEFAULT_CLIENT_SSID "" +#define CARD_DEFAULT_AP_SSID "default" +#define CARD_DEFAULT_KEY1 "default_key_1" +#define CARD_DEFAULT_KEY2 "default_key_2" +#define CARD_DEFAULT_KEY3 "default_key_3" +#define CARD_DEFAULT_KEY4 "default_key_4" +#define CARD_DEFAULT_WEP 0 +#define CARD_DEFAULT_FILTER 0 +#define CARD_DEFAULT_WDS 0 +#define CARD_DEFAULT_AUTHEN DOT11_AUTH_OS +#define CARD_DEFAULT_DOT1X 0 +#define CARD_DEFAULT_MLME_MODE DOT11_MLME_AUTO +#define CARD_DEFAULT_CONFORMANCE OID_INL_CONFORMANCE_NONE +#define CARD_DEFAULT_PROFILE DOT11_PROFILE_MIXED_G_WIFI +#define CARD_DEFAULT_MAXFRAMEBURST DOT11_MAXFRAMEBURST_MIXED_SAFE + +/* PIMFOR package definitions */ +#define PIMFOR_ETHERTYPE 0x8828 +#define PIMFOR_HEADER_SIZE 12 +#define PIMFOR_VERSION 1 +#define PIMFOR_OP_GET 0 +#define PIMFOR_OP_SET 1 +#define PIMFOR_OP_RESPONSE 2 +#define PIMFOR_OP_ERROR 3 +#define PIMFOR_OP_TRAP 4 +#define PIMFOR_OP_RESERVED 5 /* till 255 */ +#define PIMFOR_DEV_ID_MHLI_MIB 0 +#define PIMFOR_FLAG_APPLIC_ORIGIN 0x01 +#define PIMFOR_FLAG_LITTLE_ENDIAN 0x02 + +static inline void +add_le32p(u32 * le_number, u32 add) +{ + *le_number =3D cpu_to_le32(le32_to_cpup(le_number) + add); +} + +void display_buffer(char *, int); + +/* + * Type definition section + * + * the structure defines only the header allowing copyless + * frame handling + */ +typedef struct { + u8 version; + u8 operation; + u32 oid; + u8 device_id; + u8 flags; + u32 length; +} __attribute__ ((packed)) +pimfor_header_t; + +/* A received and interrupt-processed management frame, either for + * schedule_work(prism54_process_trap) or for priv->mgmt_received, + * processed by islpci_mgt_transaction(). */ +struct islpci_mgmtframe { + struct net_device *ndev; /* pointer to network device */ + pimfor_header_t *header; /* payload header, points into buf */ + void *data; /* payload ex header, points into buf */ + struct work_struct ws; /* argument for schedule_work() */ + char buf[0]; /* fragment buffer */ +}; + +int +islpci_mgt_receive(struct net_device *ndev); + +int +islpci_mgmt_rx_fill(struct net_device *ndev); + +void +islpci_mgt_cleanup_transmit(struct net_device *ndev); + +int +islpci_mgt_transaction(struct net_device *ndev, + int operation, unsigned long oid, + void *senddata, int sendlen, + struct islpci_mgmtframe **recvframe); + +static inline void +islpci_mgt_release(struct islpci_mgmtframe *frame) +{ + kfree(frame); +} + +#endif /* _ISLPCI_MGT_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/oid_mgt.c linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.4.26/drivers/net/wireless/prism54/oid_mgt.c 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.c 2004-06-23 = 05:30:04.000000000 +0000 @@ -0,0 +1,812 @@ +/* =20 + * Copyright (C) 2003,2004 Aurelien Alleaume + * + * 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 + * + * 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 "prismcompat.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" +#include "isl_oid.h" +#include "oid_mgt.h" +#include "isl_ioctl.h" + +/* to convert between channel and freq */ +const int frequency_list_bg[] =3D { 2412, 2417, 2422, 2427, 2432, 2437, 24= 42, + 2447, 2452, 2457, 2462, 2467, 2472, 2484 +}; + +const int frequency_list_a[] =3D { 5170, 5180, 5190, 5200, 5210, 5220, 523= 0, + 5240, 5260, 5280, 5300, 5320 +}; + +int +channel_of_freq(int f) +{ + int c =3D 0; + + if ((f >=3D 2412) && (f <=3D 2484)) { + while ((c < 14) && (f !=3D frequency_list_bg[c])) + c++; + return (c >=3D 14) ? 0 : ++c; + } else if ((f >=3D (int) 5170) && (f <=3D (int) 5320)) { + while ((c < 12) && (f !=3D frequency_list_a[c])) + c++; + return (c >=3D 12) ? 0 : (c + 37); + } else + return 0; +} + +#define OID_STRUCT(name,oid,s,t) [name] =3D {oid, 0, sizeof(s), t} +#define OID_STRUCT_C(name,oid,s,t) OID_STRUCT(name,oid,s,t | OID_FLAG_CACH= ED) +#define OID_U32(name,oid) OID_STRUCT(name,oid,u32,OID_TYPE_U32) +#define OID_U32_C(name,oid) OID_STRUCT_C(name,oid,u32,OID_TYPE_U32) +#define OID_STRUCT_MLME(name,oid) OID_STRUCT(name,oid,struct obj_mlme,OID_= TYPE_MLME) +#define OID_STRUCT_MLMEEX(name,oid) OID_STRUCT(name,oid,struct obj_mlmeex,= OID_TYPE_MLMEEX) + +#define OID_UNKNOWN(name,oid) OID_STRUCT(name,oid,0,0) + +struct oid_t isl_oid[] =3D { + OID_STRUCT(GEN_OID_MACADDRESS, 0x00000000, u8[6], OID_TYPE_ADDR), + OID_U32(GEN_OID_LINKSTATE, 0x00000001), + OID_UNKNOWN(GEN_OID_WATCHDOG, 0x00000002), + OID_UNKNOWN(GEN_OID_MIBOP, 0x00000003), + OID_UNKNOWN(GEN_OID_OPTIONS, 0x00000004), + OID_UNKNOWN(GEN_OID_LEDCONFIG, 0x00000005), + + /* 802.11 */ + OID_U32_C(DOT11_OID_BSSTYPE, 0x10000000), + OID_STRUCT_C(DOT11_OID_BSSID, 0x10000001, u8[6], OID_TYPE_SSID), + OID_STRUCT_C(DOT11_OID_SSID, 0x10000002, struct obj_ssid, + OID_TYPE_SSID), + OID_U32(DOT11_OID_STATE, 0x10000003), + OID_U32(DOT11_OID_AID, 0x10000004), + OID_STRUCT(DOT11_OID_COUNTRYSTRING, 0x10000005, u8[4], OID_TYPE_RAW), + OID_STRUCT_C(DOT11_OID_SSIDOVERRIDE, 0x10000006, struct obj_ssid, + OID_TYPE_SSID), + + OID_U32(DOT11_OID_MEDIUMLIMIT, 0x11000000), + OID_U32_C(DOT11_OID_BEACONPERIOD, 0x11000001), + OID_U32(DOT11_OID_DTIMPERIOD, 0x11000002), + OID_U32(DOT11_OID_ATIMWINDOW, 0x11000003), + OID_U32(DOT11_OID_LISTENINTERVAL, 0x11000004), + OID_U32(DOT11_OID_CFPPERIOD, 0x11000005), + OID_U32(DOT11_OID_CFPDURATION, 0x11000006), + + OID_U32_C(DOT11_OID_AUTHENABLE, 0x12000000), + OID_U32_C(DOT11_OID_PRIVACYINVOKED, 0x12000001), + OID_U32_C(DOT11_OID_EXUNENCRYPTED, 0x12000002), + OID_U32_C(DOT11_OID_DEFKEYID, 0x12000003), + [DOT11_OID_DEFKEYX] =3D {0x12000004, 3, sizeof (struct obj_key), + OID_FLAG_CACHED | OID_TYPE_KEY}, /* DOT11_OID_DEFKEY1,...DOT11_O= ID_DEFKEY4 */ + OID_UNKNOWN(DOT11_OID_STAKEY, 0x12000008), + OID_U32(DOT11_OID_REKEYTHRESHOLD, 0x12000009), + OID_UNKNOWN(DOT11_OID_STASC, 0x1200000a), + + OID_U32(DOT11_OID_PRIVTXREJECTED, 0x1a000000), + OID_U32(DOT11_OID_PRIVRXPLAIN, 0x1a000001), + OID_U32(DOT11_OID_PRIVRXFAILED, 0x1a000002), + OID_U32(DOT11_OID_PRIVRXNOKEY, 0x1a000003), + + OID_U32_C(DOT11_OID_RTSTHRESH, 0x13000000), + OID_U32_C(DOT11_OID_FRAGTHRESH, 0x13000001), + OID_U32_C(DOT11_OID_SHORTRETRIES, 0x13000002), + OID_U32_C(DOT11_OID_LONGRETRIES, 0x13000003), + OID_U32_C(DOT11_OID_MAXTXLIFETIME, 0x13000004), + OID_U32(DOT11_OID_MAXRXLIFETIME, 0x13000005), + OID_U32(DOT11_OID_AUTHRESPTIMEOUT, 0x13000006), + OID_U32(DOT11_OID_ASSOCRESPTIMEOUT, 0x13000007), + + OID_UNKNOWN(DOT11_OID_ALOFT_TABLE, 0x1d000000), + OID_UNKNOWN(DOT11_OID_ALOFT_CTRL_TABLE, 0x1d000001), + OID_UNKNOWN(DOT11_OID_ALOFT_RETREAT, 0x1d000002), + OID_UNKNOWN(DOT11_OID_ALOFT_PROGRESS, 0x1d000003), + OID_U32(DOT11_OID_ALOFT_FIXEDRATE, 0x1d000004), + OID_UNKNOWN(DOT11_OID_ALOFT_RSSIGRAPH, 0x1d000005), + OID_UNKNOWN(DOT11_OID_ALOFT_CONFIG, 0x1d000006), + + [DOT11_OID_VDCFX] =3D {0x1b000000, 7, 0, 0}, + OID_U32(DOT11_OID_MAXFRAMEBURST, 0x1b000008), + + OID_U32(DOT11_OID_PSM, 0x14000000), + OID_U32(DOT11_OID_CAMTIMEOUT, 0x14000001), + OID_U32(DOT11_OID_RECEIVEDTIMS, 0x14000002), + OID_U32(DOT11_OID_ROAMPREFERENCE, 0x14000003), + + OID_U32(DOT11_OID_BRIDGELOCAL, 0x15000000), + OID_U32(DOT11_OID_CLIENTS, 0x15000001), + OID_U32(DOT11_OID_CLIENTSASSOCIATED, 0x15000002), + [DOT11_OID_CLIENTX] =3D {0x15000003, 2006, 0, 0}, /* DOT11_OID_CLIENTX,..= .DOT11_OID_CLIENT2007 */ + + OID_STRUCT(DOT11_OID_CLIENTFIND, 0x150007DB, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_WDSLINKADD, 0x150007DC, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_WDSLINKREMOVE, 0x150007DD, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_EAPAUTHSTA, 0x150007DE, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_EAPUNAUTHSTA, 0x150007DF, u8[6], OID_TYPE_ADDR), + OID_U32_C(DOT11_OID_DOT1XENABLE, 0x150007E0), + OID_UNKNOWN(DOT11_OID_MICFAILURE, 0x150007E1), + OID_UNKNOWN(DOT11_OID_REKEYINDICATE, 0x150007E2), + + OID_U32(DOT11_OID_MPDUTXSUCCESSFUL, 0x16000000), + OID_U32(DOT11_OID_MPDUTXONERETRY, 0x16000001), + OID_U32(DOT11_OID_MPDUTXMULTIPLERETRIES, 0x16000002), + OID_U32(DOT11_OID_MPDUTXFAILED, 0x16000003), + OID_U32(DOT11_OID_MPDURXSUCCESSFUL, 0x16000004), + OID_U32(DOT11_OID_MPDURXDUPS, 0x16000005), + OID_U32(DOT11_OID_RTSSUCCESSFUL, 0x16000006), + OID_U32(DOT11_OID_RTSFAILED, 0x16000007), + OID_U32(DOT11_OID_ACKFAILED, 0x16000008), + OID_U32(DOT11_OID_FRAMERECEIVES, 0x16000009), + OID_U32(DOT11_OID_FRAMEERRORS, 0x1600000A), + OID_U32(DOT11_OID_FRAMEABORTS, 0x1600000B), + OID_U32(DOT11_OID_FRAMEABORTSPHY, 0x1600000C), + + OID_U32(DOT11_OID_SLOTTIME, 0x17000000), + OID_U32(DOT11_OID_CWMIN, 0x17000001), + OID_U32(DOT11_OID_CWMAX, 0x17000002), + OID_U32(DOT11_OID_ACKWINDOW, 0x17000003), + OID_U32(DOT11_OID_ANTENNARX, 0x17000004), + OID_U32(DOT11_OID_ANTENNATX, 0x17000005), + OID_U32(DOT11_OID_ANTENNADIVERSITY, 0x17000006), + OID_U32_C(DOT11_OID_CHANNEL, 0x17000007), + OID_U32_C(DOT11_OID_EDTHRESHOLD, 0x17000008), + OID_U32(DOT11_OID_PREAMBLESETTINGS, 0x17000009), + OID_STRUCT(DOT11_OID_RATES, 0x1700000A, u8[IWMAX_BITRATES + 1], + OID_TYPE_RAW), + OID_U32(DOT11_OID_CCAMODESUPPORTED, 0x1700000B), + OID_U32(DOT11_OID_CCAMODE, 0x1700000C), + OID_UNKNOWN(DOT11_OID_RSSIVECTOR, 0x1700000D), + OID_UNKNOWN(DOT11_OID_OUTPUTPOWERTABLE, 0x1700000E), + OID_U32(DOT11_OID_OUTPUTPOWER, 0x1700000F), + OID_STRUCT(DOT11_OID_SUPPORTEDRATES, 0x17000010, + u8[IWMAX_BITRATES + 1], OID_TYPE_RAW), + OID_U32_C(DOT11_OID_FREQUENCY, 0x17000011), + [DOT11_OID_SUPPORTEDFREQUENCIES] =3D + {0x17000012, 0, sizeof (struct obj_frequencies) + + sizeof (u16) * IWMAX_FREQ, OID_TYPE_FREQUENCIES}, + + OID_U32(DOT11_OID_NOISEFLOOR, 0x17000013), + OID_STRUCT(DOT11_OID_FREQUENCYACTIVITY, 0x17000014, u8[IWMAX_FREQ + 1], + OID_TYPE_RAW), + OID_UNKNOWN(DOT11_OID_IQCALIBRATIONTABLE, 0x17000015), + OID_U32(DOT11_OID_NONERPPROTECTION, 0x17000016), + OID_U32(DOT11_OID_SLOTSETTINGS, 0x17000017), + OID_U32(DOT11_OID_NONERPTIMEOUT, 0x17000018), + OID_U32(DOT11_OID_PROFILES, 0x17000019), + OID_STRUCT(DOT11_OID_EXTENDEDRATES, 0x17000020, + u8[IWMAX_BITRATES + 1], OID_TYPE_RAW), + + OID_STRUCT_MLME(DOT11_OID_DEAUTHENTICATE, 0x18000000), + OID_STRUCT_MLME(DOT11_OID_AUTHENTICATE, 0x18000001), + OID_STRUCT_MLME(DOT11_OID_DISASSOCIATE, 0x18000002), + OID_STRUCT_MLME(DOT11_OID_ASSOCIATE, 0x18000003), + OID_UNKNOWN(DOT11_OID_SCAN, 0x18000004), + OID_STRUCT_MLMEEX(DOT11_OID_BEACON, 0x18000005), + OID_STRUCT_MLMEEX(DOT11_OID_PROBE, 0x18000006), + OID_STRUCT_MLMEEX(DOT11_OID_DEAUTHENTICATEEX, 0x18000007), + OID_STRUCT_MLMEEX(DOT11_OID_AUTHENTICATEEX, 0x18000008), + OID_STRUCT_MLMEEX(DOT11_OID_DISASSOCIATEEX, 0x18000009), + OID_STRUCT_MLMEEX(DOT11_OID_ASSOCIATEEX, 0x1800000A), + OID_STRUCT_MLMEEX(DOT11_OID_REASSOCIATE, 0x1800000B), + OID_STRUCT_MLMEEX(DOT11_OID_REASSOCIATEEX, 0x1800000C), + + OID_U32(DOT11_OID_NONERPSTATUS, 0x1E000000), + + 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), + OID_STRUCT_C(DOT11_OID_PSMBUFFER, 0x19000004, struct obj_buffer, + OID_TYPE_BUFFER), + + OID_U32(DOT11_OID_BSSS, 0x1C000000), + [DOT11_OID_BSSX] =3D {0x1C000001, 63, sizeof (struct obj_bss), + OID_TYPE_BSS}, /*DOT11_OID_BSS1,...,DOT11_OID_BSS64 */ + OID_STRUCT(DOT11_OID_BSSFIND, 0x1C000042, struct obj_bss, OID_TYPE_BSS), + [DOT11_OID_BSSLIST] =3D {0x1C000043, 0, sizeof (struct + obj_bsslist) + + sizeof (struct obj_bss[IWMAX_BSS]), + OID_TYPE_BSSLIST}, + + OID_UNKNOWN(OID_INL_TUNNEL, 0xFF020000), + OID_UNKNOWN(OID_INL_MEMADDR, 0xFF020001), + 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_UNKNOWN(OID_INL_INTERFACE_ID, 0xFF020006), + OID_UNKNOWN(OID_INL_COMPONENT_ID, 0xFF020007), + OID_U32_C(OID_INL_CONFIG, 0xFF020008), + OID_U32_C(OID_INL_DOT11D_CONFORMANCE, 0xFF02000C), + OID_U32(OID_INL_PHYCAPABILITIES, 0xFF02000D), + OID_U32_C(OID_INL_OUTPUTPOWER, 0xFF02000F), + +}; + +int +mgt_init(islpci_private *priv) +{ + int i; + + priv->mib =3D kmalloc(OID_NUM_LAST * sizeof (void *), GFP_KERNEL); + if (!priv->mib) + return -ENOMEM; + + memset(priv->mib, 0, OID_NUM_LAST * sizeof (void *)); + + /* Alloc the cache */ + for (i =3D 0; i < OID_NUM_LAST; i++) { + if (isl_oid[i].flags & OID_FLAG_CACHED) { + priv->mib[i] =3D kmalloc(isl_oid[i].size * + (isl_oid[i].range + 1), + GFP_KERNEL); + if (!priv->mib[i]) + return -ENOMEM; + memset(priv->mib[i], 0, + isl_oid[i].size * (isl_oid[i].range + 1)); + } else + priv->mib[i] =3D NULL; + } + + init_rwsem(&priv->mib_sem); + prism54_mib_init(priv); + + return 0; +} + +void +mgt_clean(islpci_private *priv) +{ + int i; + + if (!priv->mib) + return; + for (i =3D 0; i < OID_NUM_LAST; i++) + if (priv->mib[i]) { + kfree(priv->mib[i]); + priv->mib[i] =3D NULL; + } + kfree(priv->mib); + priv->mib =3D NULL; +} + +void +mgt_le_to_cpu(int type, void *data) +{ + switch (type) { + case OID_TYPE_U32: + *(u32 *) data =3D le32_to_cpu(*(u32 *) data); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D data; + buff->size =3D le32_to_cpu(buff->size); + buff->addr =3D le32_to_cpu(buff->addr); + break; + } + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D data; + bss->age =3D le16_to_cpu(bss->age); + bss->channel =3D le16_to_cpu(bss->channel); + bss->capinfo =3D le16_to_cpu(bss->capinfo); + bss->rates =3D le16_to_cpu(bss->rates); + bss->basic_rates =3D le16_to_cpu(bss->basic_rates); + break; + } + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D data; + int i; + list->nr =3D le32_to_cpu(list->nr); + for (i =3D 0; i < list->nr; i++) + mgt_le_to_cpu(OID_TYPE_BSS, &list->bsslist[i]); + break; + } + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D data; + int i; + freq->nr =3D le16_to_cpu(freq->nr); + for (i =3D 0; i < freq->nr; i++) + freq->mhz[i] =3D le16_to_cpu(freq->mhz[i]); + break; + } + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D data; + mlme->id =3D le16_to_cpu(mlme->id); + mlme->state =3D le16_to_cpu(mlme->state); + mlme->code =3D le16_to_cpu(mlme->code); + break; + } + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D data; + mlme->id =3D le16_to_cpu(mlme->id); + mlme->state =3D le16_to_cpu(mlme->state); + mlme->code =3D le16_to_cpu(mlme->code); + mlme->size =3D le16_to_cpu(mlme->size); + break; + } + case OID_TYPE_SSID: + case OID_TYPE_KEY: + case OID_TYPE_ADDR: + case OID_TYPE_RAW: + break; + default: + BUG(); + } +} + +static void +mgt_cpu_to_le(int type, void *data) +{ + switch (type) { + case OID_TYPE_U32: + *(u32 *) data =3D cpu_to_le32(*(u32 *) data); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D data; + buff->size =3D cpu_to_le32(buff->size); + buff->addr =3D cpu_to_le32(buff->addr); + break; + } + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D data; + bss->age =3D cpu_to_le16(bss->age); + bss->channel =3D cpu_to_le16(bss->channel); + bss->capinfo =3D cpu_to_le16(bss->capinfo); + bss->rates =3D cpu_to_le16(bss->rates); + bss->basic_rates =3D cpu_to_le16(bss->basic_rates); + break; + } + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D data; + int i; + list->nr =3D cpu_to_le32(list->nr); + for (i =3D 0; i < list->nr; i++) + mgt_cpu_to_le(OID_TYPE_BSS, &list->bsslist[i]); + break; + } + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D data; + int i; + freq->nr =3D cpu_to_le16(freq->nr); + for (i =3D 0; i < freq->nr; i++) + freq->mhz[i] =3D cpu_to_le16(freq->mhz[i]); + break; + } + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D data; + mlme->id =3D cpu_to_le16(mlme->id); + mlme->state =3D cpu_to_le16(mlme->state); + mlme->code =3D cpu_to_le16(mlme->code); + break; + } + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D data; + mlme->id =3D cpu_to_le16(mlme->id); + mlme->state =3D cpu_to_le16(mlme->state); + mlme->code =3D cpu_to_le16(mlme->code); + mlme->size =3D cpu_to_le16(mlme->size); + break; + } + case OID_TYPE_SSID: + case OID_TYPE_KEY: + case OID_TYPE_ADDR: + case OID_TYPE_RAW: + break; + default: + BUG(); + } +} + +/* Note : data is modified during this function */ + +int +mgt_set_request(islpci_private *priv, enum oid_num_t n, int extra, void *d= ata) +{ + int ret =3D 0; + struct islpci_mgmtframe *response; + int response_op =3D PIMFOR_OP_ERROR; + int dlen; + void *cache, *_data =3D data; + u32 oid; + + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(extra > isl_oid[n].range); + + if (!priv->mib) + /* memory has been freed */ + return -1; + + dlen =3D isl_oid[n].size; + cache =3D priv->mib[n]; + cache +=3D (cache ? extra * dlen : 0); + oid =3D isl_oid[n].oid + extra; + + if (_data =3D=3D NULL) + /* we are requested to re-set a cached value */ + _data =3D cache; + else + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, _data); + /* If we are going to write to the cache, we don't want anyone to read + * it -> acquire write lock. + * Else we could acquire a read lock to be sure we don't bother the + * commit process (which takes a write lock). But I'm not sure if it's + * needed. + */ + if (cache) + down_write(&priv->mib_sem); + + if (islpci_get_state(priv) >=3D PRV_STATE_READY) { + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, oid, + _data, dlen, &response); + if (!ret) { + response_op =3D response->header->operation; + islpci_mgt_release(response); + } + if (ret || response_op =3D=3D PIMFOR_OP_ERROR) + ret =3D -EIO; + } else if (!cache) + ret =3D -EIO; + + if (cache) { + if (!ret && data) + memcpy(cache, _data, dlen); + up_write(&priv->mib_sem); + } + + /* 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 *d= ata, + union oid_res_t *res) +{ + + int ret =3D -EIO; + int reslen =3D 0; + struct islpci_mgmtframe *response =3D NULL; + + int dlen; + void *cache, *_res =3D NULL; + u32 oid; + + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(extra > isl_oid[n].range); + + if (!priv->mib) + /* memory has been freed */ + return -1; + + dlen =3D isl_oid[n].size; + cache =3D priv->mib[n]; + cache +=3D cache ? extra * dlen : 0; + oid =3D isl_oid[n].oid + extra; + reslen =3D dlen; + + if (cache) + down_read(&priv->mib_sem); + + if (islpci_get_state(priv) >=3D PRV_STATE_READY) { + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + oid, data, dlen, &response); + if (ret || !response || + response->header->operation =3D=3D PIMFOR_OP_ERROR) { + if (response) + islpci_mgt_release(response); + ret =3D -EIO; + } + if (!ret) { + _res =3D response->data; + reslen =3D response->header->length; + } + } else if (cache) { + _res =3D cache; + ret =3D 0; + } + if ((isl_oid[n].flags & OID_FLAG_TYPE) =3D=3D OID_TYPE_U32) + res->u =3D ret ? 0 : le32_to_cpu(*(u32 *) _res); + else { + res->ptr =3D kmalloc(reslen, GFP_KERNEL); + BUG_ON(res->ptr =3D=3D NULL); + if (ret) + memset(res->ptr, 0, reslen); + else { + memcpy(res->ptr, _res, reslen); + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, + res->ptr); + } + } + if (cache) + up_read(&priv->mib_sem); + + if (response && !ret) + islpci_mgt_release(response); + + if (reslen > isl_oid[n].size) + printk(KERN_DEBUG + "mgt_get_request(0x%x): received data length was bigger " + "than expected (%d > %d). Memory is probably corrupted...", + oid, reslen, isl_oid[n].size); + + return ret; +} + +/* lock outside */ +int +mgt_commit_list(islpci_private *priv, enum oid_num_t *l, int n) +{ + int i, ret =3D 0; + struct islpci_mgmtframe *response; + + for (i =3D 0; i < n; i++) { + struct oid_t *t =3D &(isl_oid[l[i]]); + void *data =3D priv->mib[l[i]]; + int j =3D 0; + u32 oid =3D t->oid; + BUG_ON(data =3D=3D NULL); + while (j <=3D t->range) { + response =3D NULL; + ret |=3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + oid, data, t->size, + &response); + if (response) { + ret |=3D (response->header->operation =3D=3D + PIMFOR_OP_ERROR); + islpci_mgt_release(response); + } + j++; + oid++; + data +=3D t->size; + } + } + return ret; +} + +/* Lock outside */ + +void +mgt_set(islpci_private *priv, enum oid_num_t n, void *data) +{ + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(priv->mib[n] =3D=3D NULL); + + memcpy(priv->mib[n], data, isl_oid[n].size); + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, priv->mib[n]); +} + +void +mgt_get(islpci_private *priv, enum oid_num_t n, void *res) +{ + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(priv->mib[n] =3D=3D NULL); + BUG_ON(res =3D=3D NULL); + + memcpy(res, priv->mib[n], isl_oid[n].size); + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, res); +} + +/* Commits the cache. Lock outside. */ + +static enum oid_num_t commit_part1[] =3D { + OID_INL_CONFIG, + OID_INL_MODE, + DOT11_OID_BSSTYPE, + DOT11_OID_CHANNEL, + DOT11_OID_MLMEAUTOLEVEL +}; + +static enum oid_num_t commit_part2[] =3D { + DOT11_OID_SSID, + DOT11_OID_PSMBUFFER, + DOT11_OID_AUTHENABLE, + DOT11_OID_PRIVACYINVOKED, + DOT11_OID_EXUNENCRYPTED, + DOT11_OID_DEFKEYX, /* MULTIPLE */ + DOT11_OID_DEFKEYID, + DOT11_OID_DOT1XENABLE, + OID_INL_DOT11D_CONFORMANCE, + OID_INL_OUTPUTPOWER, +}; + +/* update the MAC addr. */ +static int +mgt_update_addr(islpci_private *priv) +{ + struct islpci_mgmtframe *res; + int ret; + + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + isl_oid[GEN_OID_MACADDRESS].oid, NULL, + isl_oid[GEN_OID_MACADDRESS].size, &res); + + if ((ret =3D=3D 0) && res && (res->header->operation !=3D PIMFOR_OP_ERROR= )) + memcpy(priv->ndev->dev_addr, res->data, 6); + else + ret =3D -EIO; + if (res) + islpci_mgt_release(res); + + return ret; +} + +void +mgt_commit(islpci_private *priv) +{ + int rvalue; + u32 u; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return; + + rvalue =3D mgt_commit_list(priv, commit_part1, + sizeof (commit_part1) / + sizeof (commit_part1[0])); + + if (priv->iw_mode !=3D IW_MODE_MONITOR) + rvalue |=3D mgt_commit_list(priv, commit_part2, + sizeof (commit_part2) / + sizeof (commit_part2[0])); + + u =3D OID_INL_MODE; + rvalue |=3D mgt_commit_list(priv, &u, 1); + rvalue |=3D mgt_update_addr(priv); + + 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); + } +} + +/* This will tell you if you are allowed to answer a mlme(ex) request .*/ + +inline int +mgt_mlme_answer(islpci_private *priv) +{ + u32 mlmeautolevel; + /* Acquire a read lock because if we are in a mode change, it's + * possible to answer true, while the card is leaving master to managed + * mode. Answering to a mlme in this situation could hang the card. + */ + down_read(&priv->mib_sem); + mlmeautolevel =3D + le32_to_cpu(*(u32 *) priv->mib[DOT11_OID_MLMEAUTOLEVEL]); + up_read(&priv->mib_sem); + + return ((priv->iw_mode =3D=3D IW_MODE_MASTER) && + (mlmeautolevel >=3D DOT11_MLME_INTERMEDIATE)); +} + +inline enum oid_num_t +mgt_oidtonum(u32 oid) +{ + int i; + + for (i =3D 0; i < OID_NUM_LAST; i++) + if (isl_oid[i].oid =3D=3D oid) + return i; + + printk(KERN_DEBUG "looking for an unknown oid 0x%x", oid); + + return OID_NUM_LAST; +} + +int +mgt_response_to_str(enum oid_num_t n, union oid_res_t *r, char *str) +{ + switch (isl_oid[n].flags & OID_FLAG_TYPE) { + case OID_TYPE_U32: + return snprintf(str, PRIV_STR_SIZE, "%u\n", r->u); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "size=3D%u\naddr=3D0x%X\n", buff->size, + buff->addr); + } + break; + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "age=3D%u\nchannel=3D%u\n" + "capinfo=3D0x%X\nrates=3D0x%X\n" + "basic_rates=3D0x%X\n", bss->age, + bss->channel, bss->capinfo, + bss->rates, bss->basic_rates); + } + break; + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D r->ptr; + int i, k; + k =3D snprintf(str, PRIV_STR_SIZE, "nr=3D%u\n", list->nr); + for (i =3D 0; i < list->nr; i++) + k +=3D snprintf(str + k, PRIV_STR_SIZE - k, + "bss[%u] : \nage=3D%u\nchannel=3D%u\n" + "capinfo=3D0x%X\nrates=3D0x%X\n" + "basic_rates=3D0x%X\n", + i, list->bsslist[i].age, + list->bsslist[i].channel, + list->bsslist[i].capinfo, + list->bsslist[i].rates, + list->bsslist[i].basic_rates); + return k; + } + break; + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D r->ptr; + int i, t; + printk("nr : %u\n", freq->nr); + t =3D snprintf(str, PRIV_STR_SIZE, "nr=3D%u\n", freq->nr); + for (i =3D 0; i < freq->nr; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "mhz[%u]=3D%u\n", i, freq->mhz[i]); + return t; + } + break; + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=3D0x%X\nstate=3D0x%X\ncode=3D0x%X\n", + mlme->id, mlme->state, mlme->code); + } + break; + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=3D0x%X\nstate=3D0x%X\n" + "code=3D0x%X\nsize=3D0x%X\n", mlme->id, + mlme->state, mlme->code, mlme->size); + } + break; + case OID_TYPE_SSID:{ + struct obj_ssid *ssid =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "length=3D%u\noctets=3D%s\n", + ssid->length, ssid->octets); + } + break; + case OID_TYPE_KEY:{ + struct obj_key *key =3D r->ptr; + int t, i; + t =3D snprintf(str, PRIV_STR_SIZE, + "type=3D0x%X\nlength=3D0x%X\nkey=3D0x", + key->type, key->length); + for (i =3D 0; i < key->length; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "%02X:", key->key[i]); + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, "\n"); + return t; + } + break; + case OID_TYPE_RAW: + case OID_TYPE_ADDR:{ + unsigned char *buff =3D r->ptr; + int t, i; + t =3D snprintf(str, PRIV_STR_SIZE, "hex data=3D"); + for (i =3D 0; i < isl_oid[n].size; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "%02X:", buff[i]); + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, "\n"); + return t; + } + break; + default: + BUG(); + } + return 0; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/oid_mgt.h linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.h --- linux-2.4.26/drivers/net/wireless/prism54/oid_mgt.h 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.h 2004-06-23 = 05:30:04.000000000 +0000 @@ -0,0 +1,58 @@ +/* + * Copyright (C) 2003 Aurelien Alleaume + * + * 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 + * + * 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 + * + */ + +#if !defined(_OID_MGT_H) +#define _OID_MGT_H + +#include "isl_oid.h" +#include "islpci_dev.h" + +extern struct oid_t isl_oid[]; + +int mgt_init(islpci_private *); + +void mgt_clean(islpci_private *); + +/* I don't know where to put these 3 */ +extern const int frequency_list_bg[]; +extern const int frequency_list_a[]; +int channel_of_freq(int); + +void mgt_le_to_cpu(int, void *); + +int mgt_set_request(islpci_private *, enum oid_num_t, int, void *); + +int mgt_get_request(islpci_private *, enum oid_num_t, int, void *, + union oid_res_t *); + +int mgt_commit_list(islpci_private *, enum oid_num_t *, int); + +void mgt_set(islpci_private *, enum oid_num_t, void *); + +void mgt_get(islpci_private *, enum oid_num_t, void *); + +void mgt_commit(islpci_private *); + +int mgt_mlme_answer(islpci_private *); + +enum oid_num_t mgt_oidtonum(u32 oid); + +int mgt_response_to_str(enum oid_num_t, union oid_res_t *, char *); + +#endif /* !defined(_OID_MGT_H) */ +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/prismcompat.h linux-2.4.26-prism54/drivers/net/wireless/prism54/pris= mcompat.h --- linux-2.4.26/drivers/net/wireless/prism54/prismcompat.h 1970-01-01 00:0= 0:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/prismcompat.h 2004-06= -23 05:30:04.000000000 +0000 @@ -0,0 +1,46 @@ +/* =20 + * (C) 2004 Margit Schubert-While + * + * 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 + * + * 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 + * + */ + +/* =20 + * Compatibility header file to aid support of different kernel versions + */ + +#ifdef PRISM54_COMPAT24 +#include "prismcompat24.h" +#else /* PRISM54_COMPAT24 */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq(irq) + +#define PRISM_FW_PDEV &priv->pdev->dev + +#endif /* _PRISM_COMPAT_H */ +#endif /* PRISM54_COMPAT24 */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/prismcompat24.h linux-2.4.26-prism54/drivers/net/wireless/prism54/pr= ismcompat24.h --- linux-2.4.26/drivers/net/wireless/prism54/prismcompat24.h 1970-01-01 00= :00:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/prismcompat24.h 2004-= 06-23 05:30:04.000000000 +0000 @@ -0,0 +1,69 @@ +/* =20 + * (C) 2004 Margit Schubert-While + * + * 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 + * + * 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 + * + */ + +/* =20 + * Compatibility header file to aid support of different kernel versions + */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,25) +#define module_param(x, y, z) MODULE_PARM(x, "i") +#else +#include +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,23) +#define free_netdev(x) kfree(x) +#define pci_name(x) x->slot_name +#define irqreturn_t void +#define IRQ_HANDLED +#define IRQ_NONE +#else +#include +#endif + +#define work_struct tq_struct +#define INIT_WORK INIT_TQUEUE +#define schedule_work schedule_task + +#define netdev_priv(x) x->priv + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq() + +#define DEFINE_WAIT(y) DECLARE_WAITQUEUE(y, current) +#define prepare_to_wait(x, y, z) set_current_state(z); \ + add_wait_queue(x, y) +#define finish_wait(x, y) remove_wait_queue(x, y); \ + set_current_state(TASK_RUNNING) + +#define PRISM_FW_PDEV pci_name(priv->pdev) + +#endif /* _PRISM_COMPAT_H */ --9pS2hy4/DrI8BQlq-- --4T94Hejb80K+e1gX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA2RiUat1JN+IKUl4RAiY5AKCgmA9ZyQSbvOYntq4Qzzt10GEnwwCeKUP1 LpgKgcgh6CRgK8Wgy+biDm4= =JgVZ -----END PGP SIGNATURE----- --4T94Hejb80K+e1gX-- From hibi665@oki.com Tue Jun 22 23:37:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 23:37:39 -0700 (PDT) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N6bSgi026181 for ; Tue, 22 Jun 2004 23:37:29 -0700 Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id PAA18829 for ; Wed, 23 Jun 2004 15:37:26 +0900 Received: (qmail 25513 invoked from network); 23 Jun 2004 15:37:26 +0900 Received: from kiso3.bmc.oki.co.jp (HELO kiso) (172.19.233.51) by aoi.bmc.oki.co.jp with SMTP; 23 Jun 2004 15:37:26 +0900 Message-Id: <20040623153817.bcc12ea%hibi665@oki.com> MIME-Version: 1.0 Date: Wed, 23 Jun 2004 15:38:17 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com In-Reply-To: (Your message of "Mon, 21 Jun 2004 14:06:00 -0700") References: Subject: Re: About MLDv2 specification X-archive-position: 6271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev David Stevens : > Takashi, > I believe your patch will work in suppressing empty > MODE_IS_INCLUDE, but in the event the report for an empty > MODE_IS_INCLUDE is the only record, it'll still go through the > timer for all the retransmits. I want to see how hard it'd be not > to start the report timer at all for this case, and also make sure > any other changes are taken care of. The patch looks ok to me > for the interim, though. > > +-DLS > mld_send_cr() is called for retransmission of the report, but MODE_IS_INCLUDE is never used in this function. MODE_IS_INCLUDE is only used in mld_send_report(), and it is called for the response to MLDv2 query. Therefore no side effects occur, I think. Regards, Takashi Hibi From mcgrof@studorgs.rutgers.edu Tue Jun 22 23:37:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Jun 2004 23:37:39 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N6bbgi026189 for ; Tue, 22 Jun 2004 23:37:38 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 4BBD1F9D4E; Wed, 23 Jun 2004 02:37:37 -0400 (EDT) Date: Wed, 23 Jun 2004 02:37:37 -0400 To: prism54-devel@prism54.org Cc: Linux Kernel , Netdev Subject: Prism54 1.2 is out Message-ID: <20040623063737.GW6253@ruslug.rutgers.edu> Mail-Followup-To: prism54-devel@prism54.org, Linux Kernel , Netdev Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XAEV7zm15O60d1Zf" 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: 6272 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 --XAEV7zm15O60d1Zf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quick notice to developers. Prism54 1.2 is out, cvs was tagged with rel-1-2. The 2.6.7-bk3 and 2.6.7-mm1 have prism54 1.2. I just submitted prism54 1.2 to Andrew for the 2.4 stock kernel. Patches and development improvements are now welcomed but from now=20 on please submit any changes/patches for verification first with netdev. If accepted then apply to CVS. We're no longer a cheap'ol driver, our changes need to be reviewed by the good guys now ;)=20 If you're not subscribed to netdev and you are a prism54 developer,=20 please do so as prism54 development discussion should take place there now. We'll still use prism54 devel for archiving purposes (CC's to netdev). I've put some notes on the prism54.org page, if I forgot something/someone I'm sorry, please e-mail me. I'll go ahead now and=20 null out the ChangeLog so we can start 1.3 work.=20 Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --XAEV7zm15O60d1Zf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA2SUxat1JN+IKUl4RAtK2AJ9UXMNS5lNoxHwL1MQ+ruIGEOrbhgCgjO3g B3nvESbxox3mH54FpxxtANw= =7fzh -----END PGP SIGNATURE----- --XAEV7zm15O60d1Zf-- From akepner@sgi.com Wed Jun 23 02:25:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 02:25:55 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5N9Prgi001625 for ; Wed, 23 Jun 2004 02:25:53 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5MGTwhv017867 for ; Tue, 22 Jun 2004 09:29:58 -0700 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i5MGTbCe18448801; Tue, 22 Jun 2004 09:29:42 -0700 (PDT) Date: Tue, 22 Jun 2004 09:24:40 -0700 From: Arthur Kepner X-X-Sender: akepner@neteng.engr.sgi.com To: Andrew Morton cc: netdev@oss.sgi.com, "David S. Miller" , Chris Wright , Bob Gill Subject: [PATCH] preempt count regression w/ lockless loopback patch In-Reply-To: <20040621035702.6114bdbe.akpm@osdl.org> Message-ID: References: <200406210510.i5L5A340018849@hera.kernel.org> <20040621035702.6114bdbe.akpm@osdl.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1072017398-2022891538-1087921245=:1334066" Content-ID: X-archive-position: 6273 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 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. ---1072017398-2022891538-1087921245=:1334066 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Mon, 21 Jun 2004, Andrew Morton wrote: > The loopback_stats handling looks wrong: > ..... > > each get_cpu_ptr() does get_cpu(), which increments preempt_count(). But > there is only a single put_cpu_ptr() in there. Correct. At least one person has tripped over this already. (See "Re: [2.6.7-bk] NFS-related kernel panic" on lkml.) > ..... > > This compiles, but does need runtime testing. > I made one small change in get_stats() and tested with a preemptible kernel on a 32p system. Looks good. The tested patch is attached. -- Arthur ---1072017398-2022891538-1087921245=:1334066 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="patch.preempt_bug" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patch for preempt count bug Content-Disposition: ATTACHMENT; FILENAME="patch.preempt_bug" LS0tIGxpbnV4LnRtcC9kcml2ZXJzL25ldC9sb29wYmFjay5jCTIwMDQtMDYt MjIgMDk6MDA6NDEuMDAwMDAwMDAwIC0wNzAwDQorKysgbGludXgvZHJpdmVy cy9uZXQvbG9vcGJhY2suYwkyMDA0LTA2LTIyIDA5OjA2OjQxLjAwMDAwMDAw MCAtMDcwMA0KQEAgLTU1LDggKzU1LDkgQEANCiAjaW5jbHVkZSA8bGludXgv aWZfYXJwLmg+CS8qIEZvciBBUlBIUkRfRVRIRVIgKi8NCiAjaW5jbHVkZSA8 bGludXgvaXAuaD4NCiAjaW5jbHVkZSA8bGludXgvdGNwLmg+DQorI2luY2x1 ZGUgPGxpbnV4L3BlcmNwdS5oPg0KIA0KLXN0YXRpYyBzdHJ1Y3QgbmV0X2Rl dmljZV9zdGF0cyAqbG9vcGJhY2tfc3RhdHM7DQorc3RhdGljIERFRklORV9Q RVJfQ1BVKHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzLCBsb29wYmFja19zdGF0 cyk7DQogDQogI2RlZmluZSBMT09QQkFDS19PVkVSSEVBRCAoMTI4ICsgTUFY X0hFQURFUiArIDE2ICsgMTYpDQogDQpAQCAtMTI0LDYgKzEyNSw3IEBADQog ICovDQogc3RhdGljIGludCBsb29wYmFja194bWl0KHN0cnVjdCBza19idWZm ICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQogew0KKwlzdHJ1Y3Qg bmV0X2RldmljZV9zdGF0cyAqbGJfc3RhdHM7DQogDQogCXNrYl9vcnBoYW4o c2tiKTsNCiANCkBAIC0xNDIsMTMgKzE0NCwxMiBAQA0KIAl9DQogDQogCWRl di0+bGFzdF9yeCA9IGppZmZpZXM7DQotCWlmIChsaWtlbHkobG9vcGJhY2tf c3RhdHMpKSB7DQotCQlnZXRfY3B1X3B0cihsb29wYmFja19zdGF0cyktPnJ4 X2J5dGVzICs9IHNrYi0+bGVuOw0KLQkJZ2V0X2NwdV9wdHIobG9vcGJhY2tf c3RhdHMpLT50eF9ieXRlcyArPSBza2ItPmxlbjsNCi0JCWdldF9jcHVfcHRy KGxvb3BiYWNrX3N0YXRzKS0+cnhfcGFja2V0cysrOw0KLQkJZ2V0X2NwdV9w dHIobG9vcGJhY2tfc3RhdHMpLT50eF9wYWNrZXRzKys7DQotCQlwdXRfY3B1 X3B0cihsb29wYmFja19zdGF0cyk7DQotCX0NCisJbGJfc3RhdHMgPSAmcGVy X2NwdShsb29wYmFja19zdGF0cywgZ2V0X2NwdSgpKTsNCisJbGJfc3RhdHMt PnJ4X2J5dGVzICs9IHNrYi0+bGVuOw0KKwlsYl9zdGF0cy0+dHhfYnl0ZXMg Kz0gc2tiLT5sZW47DQorCWxiX3N0YXRzLT5yeF9wYWNrZXRzKys7DQorCWxi X3N0YXRzLT50eF9wYWNrZXRzKys7DQorCXB1dF9jcHUoKTsNCiANCiAJbmV0 aWZfcngoc2tiKTsNCiANCkBAIC0xNjUsMTkgKzE2NiwxOSBAQA0KIAl9DQog DQogCW1lbXNldChzdGF0cywgMCwgc2l6ZW9mKHN0cnVjdCBuZXRfZGV2aWNl X3N0YXRzKSk7DQotCWlmICghbG9vcGJhY2tfc3RhdHMpIHsNCi0JCXJldHVy biBzdGF0czsNCi0JfQ0KIA0KIAlmb3IgKGk9MDsgaSA8IE5SX0NQVVM7IGkr Kykgew0KKwkJc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKmxiX3N0YXRzOw0K Kw0KIAkJaWYgKCFjcHVfcG9zc2libGUoaSkpIA0KIAkJCWNvbnRpbnVlOw0K LQkJc3RhdHMtPnJ4X2J5dGVzICAgKz0gcGVyX2NwdV9wdHIobG9vcGJhY2tf c3RhdHMsIGkpLT5yeF9ieXRlczsNCi0JCXN0YXRzLT50eF9ieXRlcyAgICs9 IHBlcl9jcHVfcHRyKGxvb3BiYWNrX3N0YXRzLCBpKS0+dHhfYnl0ZXM7DQot CQlzdGF0cy0+cnhfcGFja2V0cyArPSBwZXJfY3B1X3B0cihsb29wYmFja19z dGF0cywgaSktPnJ4X3BhY2tldHM7DQotCQlzdGF0cy0+dHhfcGFja2V0cyAr PSBwZXJfY3B1X3B0cihsb29wYmFja19zdGF0cywgaSktPnR4X3BhY2tldHM7 DQorCQlsYl9zdGF0cyA9ICZwZXJfY3B1KGxvb3BiYWNrX3N0YXRzLCBpKTsN CisJCXN0YXRzLT5yeF9ieXRlcyAgICs9IGxiX3N0YXRzLT5yeF9ieXRlczsN CisJCXN0YXRzLT50eF9ieXRlcyAgICs9IGxiX3N0YXRzLT50eF9ieXRlczsN CisJCXN0YXRzLT5yeF9wYWNrZXRzICs9IGxiX3N0YXRzLT5yeF9wYWNrZXRz Ow0KKwkJc3RhdHMtPnR4X3BhY2tldHMgKz0gbGJfc3RhdHMtPnR4X3BhY2tl dHM7DQogCX0NCi0JCQkJDQorDQogCXJldHVybiBzdGF0czsNCiB9DQogDQpA QCAtMjEyLDggKzIxMyw2IEBADQogCQlsb29wYmFja19kZXYuZ2V0X3N0YXRz ID0gJmdldF9zdGF0czsNCiAJfQ0KIA0KLQlsb29wYmFja19zdGF0cyA9IGFs bG9jX3BlcmNwdShzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyk7DQotCQ0KIAly ZXR1cm4gcmVnaXN0ZXJfbmV0ZGV2KCZsb29wYmFja19kZXYpOw0KIH07DQog DQo= ---1072017398-2022891538-1087921245=:1334066-- From jgarzik@pobox.com Wed Jun 23 04:48:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 04:48: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.12.10/8.12.9) with SMTP id i5NBmkgi010255 for ; Wed, 23 Jun 2004 04:48:47 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bd6FB-0001tc-8T; Wed, 23 Jun 2004 12:48:45 +0100 Message-ID: <40D96E10.1060203@pobox.com> Date: Wed, 23 Jun 2004 07:48:32 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mcgrof@studorgs.rutgers.edu CC: Andrew Morton , Netdev , Linux Kernel , prism54-devel@prism54.org, Marcelo Tosatti Subject: Re: [PATCH 2.4.26] prism54: add prism54 1.2 References: <20040623054348.GV6253@ruslug.rutgers.edu> In-Reply-To: <20040623054348.GV6253@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6274 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 mcgrof@ruslug.rutgers.edu wrote: > Andrew, > > 2.6.7-bk5 and 2.6.7-mm1 are both in perfect sync with prism54 > cvs tree now. This completes our 1.2 release. As promised, > the attached patch adds prism54 1.2 to 2.4 kernel tree. Andrew is a 2.6-only guy. This is totally up to Marcelo whether to merge this new wireless stuff or not... Jeff From yoshfuji@linux-ipv6.org Wed Jun 23 06:41:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 06:41:05 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NDf1gi012877 for ; Wed, 23 Jun 2004 06:41:01 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4A8D533CE5; Wed, 23 Jun 2004 22:42:04 +0900 (JST) Date: Wed, 23 Jun 2004 22:42:03 +0900 (JST) Message-Id: <20040623.224203.122414746.yoshfuji@linux-ipv6.org> To: davem@redhat.com, clem@clem.clem-digital.net Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: 2.6.7-bk6 fails module compile -- iptable_raw.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200406231256.IAA28505@clem.clem-digital.net> References: <200406231256.IAA28505@clem.clem-digital.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: 6276 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 <200406231256.IAA28505@clem.clem-digital.net> (at Wed, 23 Jun 2004 08:56:08 -0400 (EDT)), Pete Clements says: > FYI: (gcc version 2.95.4) > > CC [M] net/ipv4/netfilter/iptable_raw.o > net/ipv4/netfilter/iptable_raw.c:57: unknown field `target_size' specified in initializer > net/ipv4/netfilter/iptable_raw.c:57: warning: missing braces around initializer > net/ipv4/netfilter/iptable_raw.c:57: warning: (near initialization for `initial_table.entries[0].target.target.u') > net/ipv4/netfilter/iptable_raw.c:71: unknown field `target_size' specified in initializer > net/ipv4/netfilter/iptable_raw.c:85: unknown field `user' specified in initializer > net/ipv4/netfilter/iptable_raw.c:87: unknown field `name' specified in initializer > net/ipv4/netfilter/iptable_raw.c:87: warning: excess elements in union initializer > net/ipv4/netfilter/iptable_raw.c:87: warning: (near initialization for `initial_table.term.target.target.u') > make[3]: *** [net/ipv4/netfilter/iptable_raw.o] Error 1 > make[2]: *** [net/ipv4/netfilter] Error 2 > make[1]: *** [net/ipv4] Error 2 > make: *** [net] Error 2 Please try this. ===== net/ipv4/netfilter/iptable_raw.c 1.2 vs edited ===== --- 1.2/net/ipv4/netfilter/iptable_raw.c 2004-06-22 06:39:19 +09:00 +++ edited/net/ipv4/netfilter/iptable_raw.c 2004-06-23 22:35:44 +09:00 @@ -54,7 +54,9 @@ }, .target = { .target = { - .u.target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), + .u = { + .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), + }, }, .verdict = -NF_ACCEPT - 1, }, @@ -68,7 +70,9 @@ }, .target = { .target = { - .u.target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), + .u = { + .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), + }, }, .verdict = -NF_ACCEPT - 1, }, @@ -82,9 +86,11 @@ }, .target = { .target = { - .u.user = { - .target_size = IPT_ALIGN(sizeof(struct ipt_error_target)), - .name = IPT_ERROR_TARGET, + .u = { + .user = { + .target_size = IPT_ALIGN(sizeof(struct ipt_error_target)), + .name = IPT_ERROR_TARGET, + }, }, }, .errorname = "ERROR", -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From mcgrof@studorgs.rutgers.edu Wed Jun 23 06:40:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 06:40:59 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NDeugi012864 for ; Wed, 23 Jun 2004 06:40:56 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id B4BCAF9D4E; Wed, 23 Jun 2004 09:40:55 -0400 (EDT) Date: Wed, 23 Jun 2004 09:40:55 -0400 To: prism54-devel@prism54.org Cc: Netdev Subject: Re: [Prism54-devel] Kernel 2.6.7-rc3 Message-ID: <20040623134055.GD6253@ruslug.rutgers.edu> Mail-Followup-To: prism54-devel@prism54.org, Netdev References: <20040610161535.GA3025@aragorn.home.lxtec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610161535.GA3025@aragorn.home.lxtec.de> 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: 6275 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 On Thu, Jun 10, 2004 at 06:15:35PM +0200, Elimar Riesebieter wrote: > Hi all, > > I had some troble with the the drivers out of vanilla 2.6.7-rc3 and > 2.6.7-rc2-mm2. Please notice that this happens running on ppc > plattform! > > This is from dmesg 2.6.7-rc3 > ---------------------------- > > eth1: islpci_open() > eth1: resetting device... > eth1: uploading firmware... > eth1: firmware uploaded done, now triggering reset... > eth1: errant PIMFOR application frame > eth1: timeout waiting for mgmt response 1000, trigging device > eth1: timeout waiting for mgmt response > eth1: Out of memory, cannot handle oid 0x5f746567 > eth1: timeout waiting for mgmt response 1000, trigging device > eth1: timeout waiting for mgmt response > eth1: errant PIMFOR application frame > eth1: timeout waiting for mgmt response 1000, trigging device > eth1: timeout waiting for mgmt respon1se > eth1: mgt_commit has failed. Restart the device > > This is a backtrace running 2.6.7-rc3 > ------------------------------------- > Jun 10 17:45:48 aragorn kernel: Bad page state at prep_new_page (in process 'cc1', page c070d020) > Jun 10 17:45:48 aragorn kernel: flags:0x00000000 mapping:00070000 mapcount:0 count:0 > Jun 10 17:45:48 aragorn kernel: Backtrace: > Jun 10 17:45:48 aragorn kernel: Call trace: > Jun 10 17:45:48 aragorn kernel: [c000b854] dump_stack+0x18/0x28 > Jun 10 17:45:48 aragorn kernel: [c003cdb0] bad_page+0x5c/0xa4 > Jun 10 17:45:48 aragorn kernel: [c003d16c] prep_new_page+0x50/0x84 > Jun 10 17:45:48 aragorn kernel: [c003d7b4] buffered_rmqueue+0x110/0x1b4 > Jun 10 17:45:48 aragorn kernel: [c003d918] __alloc_pages+0xc0/0x388 > Jun 10 17:45:48 aragorn kernel: [c0049b34] do_anonymous_page+0x70/0x1ac > Jun 10 17:45:48 aragorn kernel: [c0049cdc] do_no_page+0x6c/0x37c > Jun 10 17:45:48 aragorn kernel: [c004a1c0] handle_mm_fault+0xf4/0x174 > Jun 10 17:45:48 aragorn kernel: [c0014bf4] do_page_fault+0x140/0x398 > Jun 10 17:45:48 aragorn kernel: [c0008118] handle_page_fault+0xc/0x80 > Jun 10 17:45:48 aragorn kernel: Trying to fix it up, but a reboot is needed > > The version out of 2.6.7-rc2-mm1 runs perfect! > > Ciao > > Elimar > > -- > Numeric stability is probably not all that > important when you're guessing;-) Try 2.6.7-bk6 and if no problems occur then this has been fixed. If not please submit a bug report. Please note that mgt timeout is a known bug. This could be related to bug 88. http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=88 It is actually currently affecting WPA too but I'll send out another e-mail regarding that. -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From bernd-schubert@web.de Wed Jun 23 07:03:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 07:03:17 -0700 (PDT) Received: from mailgate4.cinetic.de (mailgate4.cinetic.de [217.72.192.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NE2vgi013912 for ; Wed, 23 Jun 2004 07:03:00 -0700 Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by mailgate4.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with ESMTP id i5MC7bH14814 for ; Tue, 22 Jun 2004 14:07:37 +0200 Received: from [80.140.15.221] (helo=bathl.lan.fli4l) by smtp08.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #26) id 1Bcjzp-0004o9-00; Tue, 22 Jun 2004 14:03:26 +0200 From: Bernd Schubert To: Herbert Xu Subject: Re: 2.6.7 error message (oops) Date: Tue, 22 Jun 2004 14:03:16 +0200 User-Agent: KMail/1.6.2 Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_KAC2AnwKo52MMms" Message-Id: <200406221403.22890.bernd-schubert@web.de> X-archive-position: 6277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd-schubert@web.de Precedence: bulk X-list: netdev --Boundary-00=_KAC2AnwKo52MMms Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 22 June 2004 12:47, Herbert Xu wrote: > Bernd Schubert wrote: > > I just booted 2.6.7 on one of our systems and see this oops from dmesg: > > > > eth11: network connection down > > Debug: sleeping function called from invalid context at > > include/asm/semaphore.h:119 > > in_atomic():0, irqs_disabled():1 > > [] dump_stack+0x1e/0x20 > > [] __might_sleep+0xb0/0xe0 > > [] netdev_run_todo+0x2b/0x290 > > [] dev_ioctl+0x269/0x300 > > [] inet_ioctl+0x8c/0xa0 > > [] sock_ioctl+0x138/0x350 > > [] sys_ioctl+0x144/0x2d0 > > [] syscall_call+0x7/0xb > > > > The device eth11 is the (ifrename) mapped eth1: > > > > sk98lin: Network Device Driver v6.23 > > OK the locking in this driver needs to be reviewed and simplified. > > In this case it's doing two spin_lock_irqsave() calls in a row on the > same flags variable. > > Does this patch fix your problem? > Thanks a lot, your patch fixed this problem! Though I had to apply it manually, since patch somehow didn't like it. Maybe it got broken when you sent the mail? Attached is the re-diffed patch (looks completely identical to me, but diff says the whitespace is different): Thanks, Bernd --Boundary-00=_KAC2AnwKo52MMms Content-Type: text/x-diff; charset="iso-8859-15"; name="diff.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.out" --- skge.c.bak Tue Jun 22 13:13:51 2004 +++ skge.c Tue Jun 22 13:30:40 2004 @@ -3093,8 +3093,7 @@ SkEventDispatcher(pAC, pAC->IoBase); for (i=0; iGIni.GIMacsFound; i++) { - spin_lock_irqsave( - &pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock); netif_stop_queue(pAC->dev[i]); } @@ -4773,12 +4772,10 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); SkGeStopPort(pAC, IoC, FromPort, SK_STOP_ALL, SK_SOFT_RST); SkGeStopPort(pAC, IoC, ToPort, SK_STOP_ALL, SK_SOFT_RST); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4791,8 +4788,7 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); pAC->ActivePort = ToPort; #if 0 SetQueueSizes(pAC); @@ -4807,8 +4803,7 @@ pAC, pAC->ActivePort, DualNet)) { - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4834,8 +4829,7 @@ SkGePollTxD(pAC, IoC, ToPort, SK_TRUE); ClearAndStartRx(pAC, FromPort); ClearAndStartRx(pAC, ToPort); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); --Boundary-00=_KAC2AnwKo52MMms-- From mcgrof@studorgs.rutgers.edu Wed Jun 23 07:15:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 07:15:18 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NEF2gi014583 for ; Wed, 23 Jun 2004 07:15:03 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id ACC26F9D4E; Wed, 23 Jun 2004 09:44:02 -0400 (EDT) Date: Wed, 23 Jun 2004 09:44:02 -0400 To: prism54-users@prism54.org Cc: Netdev Subject: Re: [Prism54-users] Prism54 1.2 released Message-ID: <20040623134402.GE6253@ruslug.rutgers.edu> Mail-Followup-To: prism54-users@prism54.org, Netdev References: <20040623064321.GX6253@ruslug.rutgers.edu> <20040623091403.GA4999@fluff> <346D1DC2D46433D94FB41A74@[192.168.1.22]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <346D1DC2D46433D94FB41A74@[192.168.1.22]> 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: 6278 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 On Wed, Jun 23, 2004 at 11:29:58AM +0200, Claas Hilbrecht wrote: > --Am Mittwoch, 23. Juni 2004 11:14 +0200 Richard Atterer > schrieb: > > >On Wed, Jun 23, 2004 at 02:43:21AM -0400, Luis R. Rodriguez wrote: > >>* A ton of bugs were fixed > > > >Does this include a fix for the problem reported by Claas Hilbrecht and > >me, that a prism54 host in master mode would take down the network once > >you tried to transmit more than a few kB/sec? > > I don't think so, since the ChangeLog doesn't contain any reference to my > bug report. And as you can see, none of the developers responded to my bug > report yet: http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=87 > > After the bug report I switch the network to Ad-hoc mode and didn't have > any problems so far. So I really think this is a driver problem or firmware > issue. > We'll have to reproduce first. We will look into it though. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From clem@clem.clem-digital.net Wed Jun 23 07:45:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 07:45:42 -0700 (PDT) Received: from clem.clem-digital.net (clem.clem-digital.net [68.16.168.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NEjIgi015322 for ; Wed, 23 Jun 2004 07:45:19 -0700 Received: (from clem@localhost) by clem.clem-digital.net (8.9.3p2/8.9.3) id KAA29786; Wed, 23 Jun 2004 10:45:01 -0400 From: Pete Clements Message-Id: <200406231445.KAA29786@clem.clem-digital.net> Subject: Re: 2.6.7-bk6 fails module compile -- iptable_raw.c In-Reply-To: <20040623.224203.122414746.yoshfuji@linux-ipv6.org> from "YOSHIFUJI Hideaki / [?iso-2022-jp?]" at "Jun 23, 2004 10:42: 3 pm" To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / [?iso-2022-jp?]) Date: Wed, 23 Jun 2004 10:45:00 -0400 (EDT) Cc: davem@redhat.com, clem@clem.clem-digital.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: clem@clem.clem-digital.net Precedence: bulk X-list: netdev Patches and compiles. Thanks. -- Pete Clements Quoting YOSHIFUJI Hideaki / [?iso-2022-jp?] > In article <200406231256.IAA28505@clem.clem-digital.net> (at Wed, 23 Jun 2004 08:56:08 -0400 (EDT)), Pete Clements says: > > > FYI: (gcc version 2.95.4) > > > > CC [M] net/ipv4/netfilter/iptable_raw.o > > net/ipv4/netfilter/iptable_raw.c:57: unknown field `target_size' specified in initializer > > net/ipv4/netfilter/iptable_raw.c:57: warning: missing braces around initializer > > net/ipv4/netfilter/iptable_raw.c:57: warning: (near initialization for `initial_table.entries[0].target.target.u') > > net/ipv4/netfilter/iptable_raw.c:71: unknown field `target_size' specified in initializer > > net/ipv4/netfilter/iptable_raw.c:85: unknown field `user' specified in initializer > > net/ipv4/netfilter/iptable_raw.c:87: unknown field `name' specified in initializer > > net/ipv4/netfilter/iptable_raw.c:87: warning: excess elements in union initializer > > net/ipv4/netfilter/iptable_raw.c:87: warning: (near initialization for `initial_table.term.target.target.u') > > make[3]: *** [net/ipv4/netfilter/iptable_raw.o] Error 1 > > make[2]: *** [net/ipv4/netfilter] Error 2 > > make[1]: *** [net/ipv4] Error 2 > > make: *** [net] Error 2 > > Please try this. > > ===== net/ipv4/netfilter/iptable_raw.c 1.2 vs edited ===== > --- 1.2/net/ipv4/netfilter/iptable_raw.c 2004-06-22 06:39:19 +09:00 > +++ edited/net/ipv4/netfilter/iptable_raw.c 2004-06-23 22:35:44 +09:00 > @@ -54,7 +54,9 @@ > }, > .target = { > .target = { > - .u.target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), > + .u = { > + .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), > + }, > }, > .verdict = -NF_ACCEPT - 1, > }, > @@ -68,7 +70,9 @@ > }, > .target = { > .target = { > - .u.target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), > + .u = { > + .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), > + }, > }, > .verdict = -NF_ACCEPT - 1, > }, > @@ -82,9 +86,11 @@ > }, > .target = { > .target = { > - .u.user = { > - .target_size = IPT_ALIGN(sizeof(struct ipt_error_target)), > - .name = IPT_ERROR_TARGET, > + .u = { > + .user = { > + .target_size = IPT_ALIGN(sizeof(struct ipt_error_target)), > + .name = IPT_ERROR_TARGET, > + }, > }, > }, > .errorname = "ERROR", > From davem@redhat.com Wed Jun 23 08:01:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 08:01:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NF19gi015856 for ; Wed, 23 Jun 2004 08:01: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 i5NF0xe1019820; Wed, 23 Jun 2004 11:00:59 -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 i5NF0w029070; Wed, 23 Jun 2004 11:00: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 i5NF0bjI011144; Wed, 23 Jun 2004 11:00:37 -0400 Date: Wed, 23 Jun 2004 08:00:27 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: clem@clem.clem-digital.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: 2.6.7-bk6 fails module compile -- iptable_raw.c Message-Id: <20040623080027.09457b66.davem@redhat.com> In-Reply-To: <20040623.224203.122414746.yoshfuji@linux-ipv6.org> References: <200406231256.IAA28505@clem.clem-digital.net> <20040623.224203.122414746.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 i5NF19gi015856 X-archive-position: 6280 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 Wed, 23 Jun 2004 22:42:03 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > net/ipv4/netfilter/iptable_raw.c:57: unknown field `target_size' specified in initializer ... > Please try this. > > ===== net/ipv4/netfilter/iptable_raw.c 1.2 vs edited ===== > --- 1.2/net/ipv4/netfilter/iptable_raw.c 2004-06-22 06:39:19 +09:00 > +++ edited/net/ipv4/netfilter/iptable_raw.c 2004-06-23 22:35:44 +09:00 Applied, thanks. From mcgrof@studorgs.rutgers.edu Wed Jun 23 08:05:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 08:05:17 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NF53gi016264 for ; Wed, 23 Jun 2004 08:05:03 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 9DD09F9D4E; Wed, 23 Jun 2004 10:28:21 -0400 (EDT) Date: Wed, 23 Jun 2004 10:28:21 -0400 To: Netdev Cc: prism54-devel@prism54.org Subject: Possible prism54 softmac software Message-ID: <20040623142821.GF6253@ruslug.rutgers.edu> Mail-Followup-To: Netdev , prism54-devel@prism54.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 6281 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 While on IRC, Viddy informed me that he found the following URLs: 09:15 < Viddy> you guys might like to know this: There is an 802.11g with the thin firmware sold by a company in nz, http://www.dse.co.nz/cgi-bin/dse.storefront/40d977e1061a835c273fc0a87f990719/Product/View/XH8196 they have some source drivers on thier webpage here: http://www.dse.co.nz/cgi-bin/dse.filereader?40d977e1061a835c273fc0a87f990719+EN/catalogs/SUPXH8196 with the actual 3meg source file here: http://www.dse.co.nz/isroot/dse/support/XH8196-linux.zip Quick review shows this could indeed be the Softmac driver source base that will allow us to support for Prism Xbow/Javelin chipsets. I don't necessarily like the license and I also noticed they used pcmcia-cs again (not necessary). Anyway, just wanted to relay the information. A lot of work ahead of us. Please review, poke, poke, etc. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From mcgrof@studorgs.rutgers.edu Wed Jun 23 09:20:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 09:20:15 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NGK9gi021242 for ; Wed, 23 Jun 2004 09:20:09 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id B0F6EF9D4E; Wed, 23 Jun 2004 12:20:08 -0400 (EDT) Date: Wed, 23 Jun 2004 12:20:08 -0400 To: Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Possible prism54 softmac software Message-ID: <20040623162008.GR6253@ruslug.rutgers.edu> Mail-Followup-To: Netdev , prism54-devel@prism54.org References: <20040623142821.GF6253@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623142821.GF6253@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: 6282 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 On Wed, Jun 23, 2004 at 10:28:21AM -0400, Luis R. Rodriguez wrote: > > While on IRC, Viddy informed me that he found the following URLs: > > 09:15 < Viddy> you guys might like to know this: There is an 802.11g > with the thin firmware sold by a company in nz, > http://www.dse.co.nz/cgi-bin/dse.storefront/40d977e1061a835c273fc0a87f990719/Product/View/XH8196 > they have some source drivers on thier > webpage here: > http://www.dse.co.nz/cgi-bin/dse.filereader?40d977e1061a835c273fc0a87f990719+EN/catalogs/SUPXH8196 > with the actual 3meg source > file here: > http://www.dse.co.nz/isroot/dse/support/XH8196-linux.zip > > Quick review shows this could indeed be the Softmac driver source base > that will allow us to support for Prism Xbow/Javelin chipsets. I don't necessarily > like the license and I also noticed they used pcmcia-cs again (not necessary). > Anyway, just wanted to relay the information. A lot of work ahead of us. > > Please review, poke, poke, etc. OK well good news is this *is* softmac code. The bad news aren't that bad: - this code is old, and very very alpha - the driver code is: 1. redistributable 2. you can modify source but you must provide source Some files have just this as the license, and some are purely GPL'd. Because of this, feel free to poke at it but just keep in mind that Conexant may provide us with a much much more updated and better source base for a softmac based driver. Because of this, use it just for your own research/playing. I wouldn't be surprised if that link goes down soon though. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From brazilnut@us.ibm.com Wed Jun 23 09:56:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 09:56:29 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NGuKgi022273 for ; Wed, 23 Jun 2004 09:56:27 -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.2) with ESMTP id i5NGuAws673894; Wed, 23 Jun 2004 12:56:10 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NGvH0r058764; Wed, 23 Jun 2004 12:57:18 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5NGq0e15930; Wed, 23 Jun 2004 09:52:00 -0700 From: Don Fry Message-Id: <200406231652.i5NGq0e15930@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 4 2.6.7-bk6] pcnet32: Fix VMWare emulation hang. To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Wed, 23 Jun 2004 09:51:59 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6283 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 A problem with the VMWare emulation was reported on lkml. This patch prevents a VMWare hang. Reported by Keith Moore . Tested by Keith on VMWare and myself on real pcnet32 adapters. signed-off-by: Don Fry --- linux-2.6.7-bk6/drivers/net/orig.pcnet32.c Wed Jun 23 08:27:33 2004 +++ linux-2.6.7-bk6/drivers/net/pcnet32.c Wed Jun 23 08:29:40 2004 @@ -1884,7 +1884,8 @@ pcnet32_interrupt(int irq, void *dev_id, } /* Set interrupt enable. */ - lp->a.write_csr (ioaddr, 0, 0x0040); + /* VMWare requires the IDON bit to remain set */ + lp->a.write_csr (ioaddr, 0, 0x0140); lp->a.write_rap (ioaddr,rap); if (netif_msg_intr(lp)) -- Don Fry brazilnut@us.ibm.com From mcgrof@studorgs.rutgers.edu Wed Jun 23 10:18:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 10:18:36 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NHIMgi023462 for ; Wed, 23 Jun 2004 10:18:23 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 6CDEAF9D4E; Wed, 23 Jun 2004 12:41:34 -0400 (EDT) Date: Wed, 23 Jun 2004 12:41:34 -0400 To: Marcelo Tosatti Cc: Andrew Morton , Netdev , Linux Kernel , prism54-devel@prism54.org, Jeff Garzik Subject: Re: [PATCH 2.4.26] prism54: add prism54 1.2 Message-ID: <20040623164134.GT6253@ruslug.rutgers.edu> Mail-Followup-To: Marcelo Tosatti , Andrew Morton , Netdev , Linux Kernel , prism54-devel@prism54.org, Jeff Garzik References: <20040623054348.GV6253@ruslug.rutgers.edu> <40D96E10.1060203@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D96E10.1060203@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: 6284 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 On Wed, Jun 23, 2004 at 07:48:32AM -0400, Jeff Garzik wrote: > mcgrof@ruslug.rutgers.edu wrote: > >Andrew, > > > >2.6.7-bk5 and 2.6.7-mm1 are both in perfect sync with prism54 > >cvs tree now. This completes our 1.2 release. As promised, > >the attached patch adds prism54 1.2 to 2.4 kernel tree. > > Andrew is a 2.6-only guy. > > This is totally up to Marcelo whether to merge this new wireless stuff > or not... > > Jeff > > Marcelo, what do you say? -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From akpm@osdl.org Wed Jun 23 10:23:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 10:23:55 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NHNqgi023862 for ; Wed, 23 Jun 2004 10:23:53 -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 i5NHNlr28132 for ; Wed, 23 Jun 2004 10:23:47 -0700 Date: Wed, 23 Jun 2004 10:22:51 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 2938] New: broken udp packets silently dropped Message-Id: <20040623102251.11654dc3.akpm@osdl.org> 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: 6285 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 Begin forwarded message: Date: Wed, 23 Jun 2004 03:02:37 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 2938] New: broken udp packets silently dropped http://bugme.osdl.org/show_bug.cgi?id=2938 Summary: broken udp packets silently dropped Kernel Version: 2.6.6 Status: NEW Severity: normal Owner: niv@us.ibm.com Submitter: martin@rabbta.com Distribution: Debian testing Hardware Environment: Intel(R) Xeon(TM) CPU 3.06GHz, Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Software Environment: iptables, netstat, tethereal Problem Description: Packets arrive to my MAC and my IP (according to output from tethereal as well as log output from iptables), but get dropped at "Routing Decision" in http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png (according to log output from iptables). No mention of new packet receive errors in "netstat -s". On a 2.4.22-kernel the listening socket gets a "Resource temporarily unavailable" and "netstat -s" shows new packet receive errors when the same source sends packets. Steps to reproduce: I will try to submit a tethereal-dump as soon as I get the possibility to do this again. But probably all you need to do is send packets with wrong checksum to a 2.6.6-kernel and watch them get silently dropped. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From P@draigBrady.com Wed Jun 23 10:35:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 10:35:51 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NHZkgi024635 for ; Wed, 23 Jun 2004 10:35:47 -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 i5NHZdOC049936; Wed, 23 Jun 2004 18:35:40 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40D9BF6B.4050807@draigBrady.com> Date: Wed, 23 Jun 2004 18:35:39 +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: e1000-devel@lists.sourceforge.net CC: netdev@oss.sgi.com Subject: Re: [E1000-devel] e1000 jumbo problems References: <40D883C2.7010106@draigBrady.com> In-Reply-To: <40D883C2.7010106@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i5NHZdOC049936 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5NHZkgi024635 X-archive-position: 6286 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 P@draigBrady.com wrote: > Another related issue, is that the driver uses 4KiB buffers > for MTUs in the 1500 -> 2000 range which seems a bit silly. > Any particular reason for that? I changed the driver to use 2KiB buffers for frames in the 1518 -> 2048 range (BSEX=0, LPE=1). This breaks however as packets are not dropped that are larger than the max specified? Instead they're scribbled into memory causing a lockup after a while. I noticed in e1000_change_mtu() that adapter->hw.max_frame_size is only set after e1000_down();e1000_up(); Is that correct? Are there any anwsers for the general questions I had even? 1. Is there a public dev tree available for the e1000 driver? 2. Are there programming docs for the various GigE chipsets? thanks, Pádraig. From brazilnut@us.ibm.com Wed Jun 23 11:20:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 11:20:44 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NIKWgi025885 for ; Wed, 23 Jun 2004 11:20:39 -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.2) with ESMTP id i5NIKCkw465990; Wed, 23 Jun 2004 14:20:14 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NILJ0r112076; Wed, 23 Jun 2004 14:21:20 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5NIG5J16003; Wed, 23 Jun 2004 11:16:05 -0700 From: Don Fry Message-Id: <200406231816.i5NIG5J16003@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 5 2.6.7-bk6] pcnet32: Add HomePNA parameter for 79C978. To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Wed, 23 Jun 2004 11:16:05 -0700 (PDT) Cc: psimmons@flash.net X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6287 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 This patch adds a module parameter to select HomePNA mode of operation for the 79C978 version of the pcnet32. Tested ia32 and ppc64. signed-off-by: Patrick Simmons signed-off-by: Don Fry --- linux-2.6.7-bk6/drivers/net/vmw.pcnet32.c Wed Jun 23 09:00:01 2004 +++ linux-2.6.7-bk6/drivers/net/pcnet32.c Wed Jun 23 09:00:05 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30f" -#define DRV_RELDATE "06.16.2004" +#define DRV_VERSION "1.30g" +#define DRV_RELDATE "06.22.2004" #define PFX DRV_NAME ": " static const char *version = @@ -137,6 +137,7 @@ static const char pcnet32_gstrings_test[ #define MAX_UNITS 8 /* More are supported, limit only on options */ static int options[MAX_UNITS]; static int full_duplex[MAX_UNITS]; +static int homepna[MAX_UNITS]; /* * Theory of Operation @@ -250,6 +251,8 @@ static int full_duplex[MAX_UNITS]; * v1.30f 16 Jun 2004 Don Fry cleanup IRQ to allow 0 and 1 for PCI, * expanding on suggestions from Ralf Baechle , * and Brian Murphy . + * v1.30g 22 Jun 2004 Patrick Simmons added option + * homepna for selecting HomePNA mode for PCNet/Home 79C978. */ @@ -1084,15 +1087,17 @@ pcnet32_probe1(unsigned long ioaddr, int fdx = 1; /* * This is based on specs published at www.amd.com. This section - * assumes that a card with a 79C978 wants to go into 1Mb HomePNA - * mode. The 79C978 can also go into standard ethernet, and there - * probably should be some sort of module option to select the - * mode by which the card should operate + * assumes that a card with a 79C978 wants to go into standard + * ethernet mode. The 79C978 can also go into 1Mb HomePNA mode, + * and the module option homepna=1 can select this instead. */ - /* switch to home wiring mode */ media = a->read_bcr(ioaddr, 49); + media &= ~3; /* default to 10Mb ethernet */ + if (cards_found < MAX_UNITS && homepna[cards_found]) + media |= 1; /* switch to home wiring mode */ if (pcnet32_debug & NETIF_MSG_PROBE) - printk(KERN_DEBUG PFX "media reset to %#x.\n", media); + printk(KERN_DEBUG PFX "media set to %sMbit mode.\n", + (media & 1) ? "1" : "10"); a->write_bcr(ioaddr, 49, media); break; case 0x2627: @@ -2262,6 +2267,9 @@ MODULE_PARM(options, "1-" __MODULE_STRIN MODULE_PARM_DESC(options, DRV_NAME " initial option setting(s) (0-15)"); MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM_DESC(full_duplex, DRV_NAME " full duplex setting(s) (1)"); +/* Module Parameter for HomePNA cards added by Patrick Simmons, 2004 */ +MODULE_PARM(homepna,"1-" __MODULE_STRING(MAX_UNITS) "i"); +MODULE_PARM_DESC(homepna, DRV_NAME " mode for 79C978 cards (1 for HomePNA, 0 for Ethernet, default Ethernet"); MODULE_AUTHOR("Thomas Bogendoerfer"); MODULE_DESCRIPTION("Driver for PCnet32 and PCnetPCI based ethercards"); -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Wed Jun 23 13:13:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 13:13:12 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NKCxgi031273 for ; Wed, 23 Jun 2004 13:13:08 -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.2) with ESMTP id i5NKCn7R494190; Wed, 23 Jun 2004 16:12:49 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NKDu0r114664; Wed, 23 Jun 2004 16:13:56 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5NK8g016457; Wed, 23 Jun 2004 13:08:42 -0700 Date: Wed, 23 Jun 2004 13:08:42 -0700 From: Don Fry To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 4 2.6.7-bk6] pcnet32: Fix VMWare emulation hang. Message-ID: <20040623130842.A16454@DYN318364BLD.beaverton.ibm.com> References: <200406231652.i5NGq0e15930@DYN318364BLD.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200406231652.i5NGq0e15930@DYN318364BLD.beaverton.ibm.com>; from brazilnut@us.ibm.com on Wed, Jun 23, 2004 at 09:51:59AM -0700 X-archive-position: 6288 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 I believe I was a bit hasty with this patch. After reading the other comments associated with this thread, and doing some more testing, I would like to cancel this patch and I will send a replacement after some testing with VMWare. -- Don Fry brazilnut@us.ibm.com From dane@aiinet.com Wed Jun 23 13:36:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 13:37:07 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NKawgi031951 for ; Wed, 23 Jun 2004 13:36:59 -0700 Received: from dane-linux.aiinet.priv ([10.39.3.117]) by AIMAIL1.ai.aiinet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LSH5ZL17; Wed, 23 Jun 2004 16:36:48 -0400 Date: Wed, 23 Jun 2004 16:37:06 -0400 (EDT) From: Dan Eble X-X-Sender: dane@dane-linux.aiinet.priv Reply-To: dane@aiinet.com To: netdev@oss.sgi.com Subject: [FYI PATCH] Ethernet over Cisco HDLC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6289 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 I don't expect this patch to apply to any recent versions of the kernel. I'm posting it in case there is someone interested in porting it. If someone has the time to comment on the locking during dev destruction, I would appreciate receiving pointers. Any other comments are welcome too. [To Krzysztof Halasa: All my mail to your pm.waw address bounces. Is there an alternate address I can use to contact you?] -- Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| diff -10 -wbBurN Old/include/linux/hdlc/ioctl.h New/include/linux/hdlc/ioctl.h --- Old/include/linux/hdlc/ioctl.h 2004-06-23 13:59:58.000000000 -0400 +++ New/include/linux/hdlc/ioctl.h 2004-06-23 16:19:07.000000000 -0400 @@ -38,15 +38,20 @@ typedef struct { unsigned int dlci; char master[IFNAMSIZ]; /* Name of master FRAD device */ }fr_proto_pvc_info; /* for returning PVC information only */ typedef struct { unsigned int interval; unsigned int timeout; } cisco_proto; +typedef struct { /* for enabling/disabling certain encapsulated protocols */ + unsigned short proto; + char name[IFNAMSIZ]; /* filled in by driver */ +} cisco_proto_inner; + typedef struct { int channel; /* read-only index assigned by generic PPP layer */ } ppp_proto; #endif /* __HDLC_IOCTL_H__ */ diff -10 -wbBurN Old/include/linux/hdlc.h New/include/linux/hdlc.h --- Old/include/linux/hdlc.h 2004-06-23 13:59:57.000000000 -0400 +++ New/include/linux/hdlc.h 2004-06-23 16:19:07.000000000 -0400 @@ -214,20 +214,25 @@ struct { cisco_proto settings; struct timer_list timer; int last_poll; int up; u32 txseq; /* TX sequence number */ u32 rxseq; /* RX sequence number */ u32 mineseen; /* echoed sequence number from remote */ + + struct hdlc_cisco_br_eth { + struct net_device dev; /* must be first */ + struct net_device_stats stats; + } *cbe; /* cbe == Cisco bridged ethernet */ }cisco; struct { raw_hdlc_proto settings; }raw_hdlc; struct { ppp_proto settings; unsigned int flags; diff -10 -wbBurN Old/include/linux/if_ether.h New/include/linux/if_ether.h --- Old/include/linux/if_ether.h 2004-06-23 13:59:58.000000000 -0400 +++ New/include/linux/if_ether.h 2004-06-23 16:19:07.000000000 -0400 @@ -47,20 +47,21 @@ #define ETH_P_IEEEPUP 0x0a00 /* Xerox IEEE802.3 PUP packet */ #define ETH_P_IEEEPUPAT 0x0a01 /* Xerox IEEE802.3 PUP Addr Trans packet */ #define ETH_P_DEC 0x6000 /* DEC Assigned proto */ #define ETH_P_DNA_DL 0x6001 /* DEC DNA Dump/Load */ #define ETH_P_DNA_RC 0x6002 /* DEC DNA Remote Console */ #define ETH_P_DNA_RT 0x6003 /* DEC DNA Routing */ #define ETH_P_LAT 0x6004 /* DEC LAT */ #define ETH_P_DIAG 0x6005 /* DEC Diagnostics */ #define ETH_P_CUST 0x6006 /* DEC Customer use */ #define ETH_P_SCA 0x6007 /* DEC Systems Comms Arch */ +#define ETH_P_ETH_BR 0x6558 /* Trans Ether Bridging [RFC1701] */ #define ETH_P_RARP 0x8035 /* Reverse Addr Res packet */ #define ETH_P_ATALK 0x809B /* Appletalk DDP */ #define ETH_P_AARP 0x80F3 /* Appletalk AARP */ #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_PPP_DISC 0x8863 /* PPPoE discovery messages */ #define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */ #define ETH_P_ATMMPOA 0x884c /* MultiProtocol Over ATM */ #define ETH_P_ATMFATE 0x8884 /* Frame-based ATM Transport diff -10 -wbBurN Old/include/linux/if.h New/include/linux/if.h --- Old/include/linux/if.h 2004-06-23 13:59:58.000000000 -0400 +++ New/include/linux/if.h 2004-06-23 16:19:07.000000000 -0400 @@ -69,20 +69,22 @@ #define IF_PROTO_CISCO 0x2002 /* Cisco HDLC protocol */ #define IF_PROTO_FR 0x2003 /* Frame Relay protocol */ #define IF_PROTO_FR_ADD_PVC 0x2004 /* Create FR PVC */ #define IF_PROTO_FR_DEL_PVC 0x2005 /* Delete FR PVC */ #define IF_PROTO_X25 0x2006 /* X.25 */ #define IF_PROTO_HDLC_ETH 0x2007 /* raw HDLC, Ethernet emulation */ #define IF_PROTO_FR_ADD_ETH_PVC 0x2008 /* Create FR Ethernet-bridged PVC */ #define IF_PROTO_FR_DEL_ETH_PVC 0x2009 /* Delete FR Ethernet-bridged PVC */ #define IF_PROTO_FR_PVC 0x200A /* for reading PVC status */ #define IF_PROTO_FR_ETH_PVC 0x200B +#define IF_PROTO_CISCO_ENABLE_PROTO 0x200C /* enable an encapsulated proto */ +#define IF_PROTO_CISCO_DISABLE_PROTO 0x200D /* disable an encapsulated proto */ /* * Device mapping structure. I'd just gone off and designed a * beautiful scheme using only loadable modules with arguments * for driver options and along come the PCMCIA people 8) * * Ah well. The get() side of this is good for WDSETUP, and it'll * be handy for debugging things. The set side is fine for now and * being very small might be worth keeping for clean configuration. @@ -100,20 +102,21 @@ }; struct if_settings { unsigned int type; /* Type of physical device or protocol */ unsigned int size; /* Size of the data allocated by the caller */ union { /* {atm/eth/dsl}_settings anyone ? */ raw_hdlc_proto *raw_hdlc; cisco_proto *cisco; + cisco_proto_inner *cisco_inner; fr_proto *fr; fr_proto_pvc *fr_pvc; fr_proto_pvc_info *fr_pvc_info; ppp_proto *ppp; /* interface settings */ sync_serial_settings *sync; te1_settings *te1; } ifs_ifsu; }; diff -10 -wbBurN Old/drivers/net/wan/hdlc_cisco.c New/drivers/net/wan/hdlc_cisco.c --- Old/drivers/net/wan/hdlc_cisco.c 2004-06-23 13:59:57.000000000 -0400 +++ New/drivers/net/wan/hdlc_cisco.c 2004-06-23 16:19:07.000000000 -0400 @@ -13,50 +13,89 @@ #include #include #include #include #include #include #include #include #include #include +#include #include #include #include #include "hdlc_proc.h" #define CISCO_MULTICAST 0x8F /* Cisco multicast address */ #define CISCO_UNICAST 0x0F /* Cisco unicast address */ +#define CISCO_IEEE_802_1D 0x4242 /* Spanning Tree PDU */ #define CISCO_KEEPALIVE 0x8035 /* Cisco keepalive protocol */ #define CISCO_SYS_INFO 0x2000 /* Cisco interface/system info */ #define CISCO_ADDR_REQ 0 /* Cisco address request */ #define CISCO_ADDR_REPLY 1 /* Cisco address reply */ #define CISCO_KEEPALIVE_REQ 2 /* Cisco keepalive request */ +static __inline__ int cbe_create(struct hdlc_device_struct *hdlc); +static __inline__ int cbe_destroy(struct hdlc_device_struct *hdlc); +static struct net_device_stats* cbe_stats(struct net_device *edev); +static int cbe_ioctl(struct net_device *edev, struct ifreq *ifr, int cmd); +static int cbe_start_xmit(struct sk_buff *skb, struct net_device *edev); + +static __inline__ struct hdlc_cisco_br_eth* +dev_to_cbe(struct net_device *dev) +{ + /* the net_device is the first member of hdlc_cisco_br_eth */ + return (struct hdlc_cisco_br_eth*)dev; +} + +static __inline__ struct net_device * +cbe_to_dev(struct hdlc_cisco_br_eth *cbe) +{ + /* the net_device is the first member of hdlc_cisco_br_eth */ + return (struct net_device*)cbe; +} + +static __inline__ struct hdlc_device_struct* +cbe_to_hdlc(struct hdlc_cisco_br_eth *cbe) +{ + return (struct hdlc_device_struct*)cbe->dev.priv; +} + +/* IEEE 802.1D bridge PDU destination address */ +static const __u8 IEEE_802_1D_DSTADDR[ETH_ALEN] = { 1, 0x80, 0xC2, 0, 0, 0 }; + +/* A few bytes that are present when and IEEE 802.1D bridge PDU is + * packed into an IEEE 802.3 frame. */ +static const __u8 IEEE_802_1D_802_2_HDR[] = { 0x42, 0x42, 0x03 }; static int cisco_hard_header(struct sk_buff *skb, struct net_device *dev, u16 type, void *daddr, void *saddr, unsigned int len) { hdlc_header *data; #ifdef CONFIG_HDLC_DEBUG_HARD_HEADER printk(KERN_DEBUG "hdlc: %s: cisco_hard_header called\n", dev->name); #endif skb_push(skb, sizeof(hdlc_header)); data = (hdlc_header*)skb->data; - if (type == CISCO_KEEPALIVE) + switch (type) { + case CISCO_IEEE_802_1D: + case CISCO_KEEPALIVE: data->address = CISCO_MULTICAST; - else + break; + default: data->address = CISCO_UNICAST; + break; + } data->control = 0; data->protocol = htons(type); return sizeof(hdlc_header); } static void cisco_keepalive_send(hdlc_device *hdlc, u32 type, u32 par1, u32 par2) @@ -201,53 +240,102 @@ case CISCO_ADDR_REPLY: printk(KERN_INFO "hdlc: %s: Unexpected Cisco IP address " "reply\n", hdlc_to_name(hdlc)); goto rx_error; case CISCO_KEEPALIVE_REQ: hdlc->state.cisco.rxseq = ntohl(cisco_data->par1); hdlc->state.cisco.mineseen = ntohl(cisco_data->par2); - // DWD - allow sequence numbers to be off by one. This copes with the race condition of - // having both ends transmitting keepalives at the same time -#if 1 + /* Allow sequence numbers to be off by one. This copes + * with the race condition of having both ends + * transmitting keepalives at the same time */ if ((hdlc->state.cisco.mineseen == hdlc->state.cisco.txseq) || (hdlc->state.cisco.mineseen == (hdlc->state.cisco.txseq-1))) { -#else - if (ntohl(cisco_data->par2) == hdlc->state.cisco.txseq) { -#endif hdlc->state.cisco.last_poll = jiffies; if (!hdlc->state.cisco.up) { -#if 0 // DWD - the uptime reporting provides strange values +#if 0 /* DWD - the uptime reporting provides strange values */ if (skb->len >= CISCO_UPTIME_PACKET_LEN) { cisco_log_link_uptime(hdlc, ntohl(cisco_data->time)); } else #endif { cisco_log_link_up(hdlc); } } hdlc->state.cisco.up = 1; } dev_kfree_skb_any(skb); return; } /* switch(keepalive type) */ + break; + + case CISCO_IEEE_802_1D: + if (!hdlc->state.cisco.cbe) + goto rx_drop; + + if (skb_cow(skb, ETH_HLEN+sizeof(IEEE_802_1D_802_2_HDR)) != 0) + goto rx_drop; + + /* Prepend the 802.2 SSAP, DSAP and control byte. */ + memcpy(skb_push(skb, sizeof(IEEE_802_1D_802_2_HDR)), + IEEE_802_1D_802_2_HDR, + sizeof(IEEE_802_1D_802_2_HDR)); + + /* Prepend an 802.3 header. */ + { + struct ethhdr *eth = + (struct ethhdr *)skb_push(skb, ETH_HLEN); + memcpy(eth->h_dest, IEEE_802_1D_DSTADDR, ETH_ALEN); + memset(eth->h_source, 0, ETH_ALEN); + eth->h_proto = htons(skb->len - ETH_HLEN); + } + + /* FALL THROUGH to ETH_P_ETH_BR */ + + case ETH_P_ETH_BR: + if (hdlc->state.cisco.cbe) + { + struct net_device *const edev = + cbe_to_dev(hdlc->state.cisco.cbe); + + /* Assign this buffer to the bridged eth dev. */ + skb->dev = edev; + + /* Parse the ethernet header. Because of the + * increased hard_header_len, eth_type_trans() + * skips too much, so push some back afterward. */ + skb->protocol = eth_type_trans(skb, edev); + skb_push(skb, edev->hard_header_len - ETH_HLEN); + + /* Receive the buffer on the bridged eth dev. */ + netif_rx(skb); + edev->last_rx = jiffies; + return; + } + goto rx_drop; + } /* switch(protocol) */ printk(KERN_INFO "hdlc: %s: Unsupported protocol %x\n", hdlc_to_name(hdlc), data->protocol); dev_kfree_skb_any(skb); return; + rx_drop: + dev_kfree_skb_any(skb); + hdlc->stats.rx_dropped++; + return; + rx_error: hdlc->stats.rx_errors++; /* Mark error */ dev_kfree_skb_any(skb); } static void cisco_timer(unsigned long arg) { hdlc_device *hdlc = (hdlc_device*)arg; @@ -292,21 +380,27 @@ } static void cisco_close(hdlc_device *hdlc) { hdlc_proc_session_clean(hdlc); del_timer_sync(&hdlc->state.cisco.timer); } +static void cisco_destroy(struct hdlc_device_struct *hdlc) +{ + cbe_destroy(hdlc); + /* Return dev attributes to their defaults set in hdlc_generic.c. */ + hdlc_to_dev(hdlc)->hard_header_len = 16; +} int hdlc_cisco_ioctl(hdlc_device *hdlc, struct ifreq *ifr) { cisco_proto *cisco_s = ifr->ifr_settings.ifs_ifsu.cisco; const size_t size = sizeof(cisco_proto); cisco_proto new_settings; struct net_device *dev = hdlc_to_dev(hdlc); int result; switch (ifr->ifr_settings.type) { @@ -337,28 +431,111 @@ result=hdlc->attach(hdlc, ENCODING_NRZ,PARITY_CRC16_PR1_CCITT); if (result) return result; hdlc_proto_detach(hdlc); memcpy(&hdlc->state.cisco.settings, &new_settings, size); hdlc->open = cisco_open; hdlc->stop = cisco_close; + hdlc->proto_detach = cisco_destroy; hdlc->netif_rx = cisco_rx; hdlc->type_trans = cisco_type_trans; hdlc->proto = IF_PROTO_CISCO; dev->hard_start_xmit = hdlc->xmit; dev->hard_header = cisco_hard_header; + dev->hard_header_len = sizeof(hdlc_header); dev->type = ARPHRD_CISCO; dev->addr_len = 0; + return 0; + + case IF_PROTO_CISCO_ENABLE_PROTO: + { + cisco_proto_inner inner; + + if(!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (copy_from_user(&inner, + ifr->ifr_settings.ifs_ifsu.cisco_inner, + sizeof(inner))) + return -EFAULT; + + switch (inner.proto) + { + case ETH_P_ETH_BR: + result = cbe_create(hdlc); + if (0 == result) + { + strncpy(inner.name, + cbe_to_dev(hdlc->state.cisco.cbe)->name, + IFNAMSIZ); + } + break; + + default: + result = -EINVAL; + break; + } + + if (0 == result) { + if (copy_to_user( + ifr->ifr_settings.ifs_ifsu.cisco_inner, + &inner, sizeof(inner))) + return -EFAULT; + } + + return result; + } + + case IF_PROTO_CISCO_DISABLE_PROTO: + { + cisco_proto_inner inner; + + if(!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (copy_from_user(&inner, + ifr->ifr_settings.ifs_ifsu.cisco_inner, + sizeof(inner))) + return -EFAULT; + + switch (inner.proto) + { + case ETH_P_ETH_BR: + if (hdlc->state.cisco.cbe) { + strncpy(inner.name, + cbe_to_dev(hdlc->state.cisco.cbe)->name, + IFNAMSIZ); + result = cbe_destroy(hdlc); + } else { + result = -EINVAL; + } + break; + + default: + result = -EINVAL; + break; + } + + if (0 == result) { + if (copy_to_user( + ifr->ifr_settings.ifs_ifsu.cisco_inner, + &inner, sizeof(inner))) + return -EFAULT; + } + + return result; + } + } return -EINVAL; } /** * Get the Debug level */ int hdlc_cisco_get_Debug(hdlc_device *hdlc, void *debug) @@ -401,14 +578,193 @@ { *(int *)yourseen = hdlc->state.cisco.rxseq; return 0; } /** * Get MineSeen */ int hdlc_cisco_get_MineSeen(hdlc_device *hdlc, void *mineseen) { -// need to store this for retreival +/* need to store this for retrieval */ *(int *)mineseen = hdlc->state.cisco.mineseen; return 0; } + +/** + * Allocate, initialize, and register a device for bridging Ethernet/802.3. + */ +static __inline__ int cbe_create(struct hdlc_device_struct *hdlc) +{ + struct hdlc_cisco_br_eth *cbe; + struct net_device *const hdev = hdlc_to_dev(hdlc); /* HDLC device */ + struct net_device *edev; /* "ethernet" device */ + int ret = 0; + + /* "cbe" eventually is freed by unregister_netdevice() */ + cbe = kmalloc(sizeof(*cbe), GFP_KERNEL); + if (!cbe) { + ret = -ENOMEM; + goto err; + } + + memset(cbe, 0, sizeof(*cbe)); + edev = cbe_to_dev(cbe); + + ether_setup(edev); + edev->priv = hdlc; + + /* Reserve space for the ethernet header. */ + edev->hard_header_len = hdev->hard_header_len + ETH_HLEN; + edev->mtu = hdev->mtu - ETH_HLEN; + if (edev->mtu > ETH_DATA_LEN) + edev->mtu = ETH_DATA_LEN; + + edev->hard_start_xmit = cbe_start_xmit; + edev->get_stats = cbe_stats; + edev->do_ioctl = cbe_ioctl; + edev->tx_queue_len = 0; /* let underlying device queue packets */ + edev->features |= NETIF_F_DYNALLOC; + + /* Assign the name of the ethernet device by appending "eth0" to + * the name of the underlying HDLC device. */ + snprintf(edev->name, IFNAMSIZ, "%seth0", hdev->name); + + ret = register_netdevice(edev); + if (ret != 0) { + printk(KERN_ERR "hdlc_cisco: could not register dev %s (%d)\n", + edev->name, ret); + goto err; + } else { + /* After this, cisco_rx() will send packets to the new dev. */ + hdlc->state.cisco.cbe = cbe; + } + + return ret; + + err: + if (cbe) + kfree(cbe); + return ret; +} + +/** + * Unregister and deallocate the device for bridging Ethernet/802.3. + */ +static __inline__ int cbe_destroy(struct hdlc_device_struct *hdlc) +{ + struct hdlc_cisco_br_eth *const cbe = hdlc->state.cisco.cbe; + int result = -EINVAL; + + if (cbe) + { + unsigned long flags; + + /* Dissociate the devices. */ + + /* lock against cisco_rx() */ + local_irq_save(flags); + hdlc->state.cisco.cbe = NULL; + local_irq_restore(flags); + + /* lock against cbe_start_xmit() */ + spin_lock_bh(&cbe_to_dev(cbe)->xmit_lock); + cbe_to_dev(cbe)->priv = NULL; + spin_unlock_bh(&cbe_to_dev(cbe)->xmit_lock); + + unregister_netdevice(cbe_to_dev(cbe)); + + result = 0; + } + + return result; +} + +static struct net_device_stats* cbe_stats(struct net_device *edev) +{ + struct hdlc_cisco_br_eth *const cbe = dev_to_cbe(edev); + if (cbe) + { + return &cbe->stats; + } + + return NULL; +} + +static int cbe_ioctl(struct net_device *edev, struct ifreq *ifr, int cmd) +{ + return -EOPNOTSUPP; +} + +static int cbe_start_xmit(struct sk_buff *skb, struct net_device *edev) +{ + struct hdlc_cisco_br_eth *const cbe = dev_to_cbe(edev); + struct hdlc_device_struct *const hdlc = cbe_to_hdlc(cbe); + + if (hdlc) { + struct net_device *const hdev = hdlc_to_dev(hdlc); + unsigned short cproto; /* cisco protocol type */ + unsigned short kproto; /* kernel protocol type */ + + /* If the MTU of the underlying HDLC interface is too + * small to encapsulate the largest ethernet frame + * (based on the MTU of this device), drop all + * packets. Even the packets that are small enough to + * fit are dropped, in order to make it impossible to + * overlook the misconfiguration. + * + * I have decided against enforcing MTU restrictions + * in the dev->change_mtu() functions because I do not + * want to force users to configure the devices in a + * certain order (and a different order, depending on + * whether the change is an increase or a decrease). + * + * I have also decided (for the time being) not to log + * a message. The device stats will record dropped + * packets, and MTU is one of the things that should + * be checked in that circumstance. + */ + if (hdev->mtu < ETH_HLEN + edev->mtu) + goto tx_drop; + + /* make sure we can push/pull without side effects */ + skb = skb_share_check(skb, GFP_ATOMIC); + if (!skb) + goto tx_dropped; + + /* IEEE 802.1D PDUs get encapsulated without an ethernet header + * and with a distinct Cisco protocol type. */ + if (pskb_may_pull(skb, + ETH_HLEN + sizeof(IEEE_802_1D_802_2_HDR)) && + (0 == memcmp(skb->data, IEEE_802_1D_DSTADDR, ETH_ALEN)) && + (0 == memcmp(&skb->data[ETH_HLEN], IEEE_802_1D_802_2_HDR, + sizeof(IEEE_802_1D_802_2_HDR)))) { + cproto = CISCO_IEEE_802_1D; + kproto = ETH_P_HDLC; + skb_pull(skb, ETH_HLEN+sizeof(IEEE_802_1D_802_2_HDR)); + } else { /* other frames get encapsulated verbatim */ + cproto = ETH_P_ETH_BR; + kproto = ETH_P_ETH_BR; + } + + skb->dev = hdev; /* send through the HDLC interface */ + skb->protocol = __constant_htons(kproto); + + if (skb_cow(skb, hdev->hard_header_len) != 0) + goto tx_drop; + + if (!cisco_hard_header(skb, skb->dev, cproto, + NULL, NULL, skb->len)) + goto tx_drop; + + ++cbe->stats.tx_packets; + cbe->stats.tx_bytes += skb->len; + dev_queue_xmit(skb); + return 0; + } + + tx_drop: + kfree_skb(skb); + tx_dropped: + ++cbe->stats.tx_dropped; + return 0; +} From brazilnut@us.ibm.com Wed Jun 23 14:18:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 14:18:06 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NLHugi002670 for ; Wed, 23 Jun 2004 14:18:02 -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.2) with ESMTP id i5NLHjws792184; Wed, 23 Jun 2004 17:17:45 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NLIq0r109008; Wed, 23 Jun 2004 17:18:52 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5NLDcx16514; Wed, 23 Jun 2004 14:13:38 -0700 From: Don Fry Message-Id: <200406232113.i5NLDcx16514@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 4 2.6.7-bk6] pcnet32: acknowledge all interrupts early. To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Wed, 23 Jun 2004 14:13:37 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6290 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 A recent change I made broke pcnet32 in a way that allowed real hardware to work, but broke VMWare. This patch acknowledges all interrupts early in the pcnet32_interrupt while loop. Without this patch on real hardware the first transmit operation would clear the 'init' interrupt, but in VMWare it would rain interrupts. Keith Moore did more testing for me on VMWare and I did a better job testing on hardware. Petr Vandrovec correctly pointed out the source of the problem on lkml. This patch is not needed for 2.4.27-rc1 unless my patch labeled "pcnet32: recover after rx hang" is applied (which it has not). signed-off-by: Don Fry --- linux-2.6.7-bk6/drivers/net/orig.pcnet32.c Wed Jun 23 08:59:52 2004 +++ linux-2.6.7-bk6/drivers/net/pcnet32.c Wed Jun 23 12:56:09 2004 @@ -1753,7 +1753,7 @@ pcnet32_interrupt(int irq, void *dev_id, spin_lock(&lp->lock); rap = lp->a.read_rap(ioaddr); - while ((csr0 = lp->a.read_csr (ioaddr, 0)) & 0x8600 && --boguscnt >= 0) { + while ((csr0 = lp->a.read_csr (ioaddr, 0)) & 0x8f00 && --boguscnt >= 0) { if (csr0 == 0xffff) { break; /* PCMCIA remove happened */ } -- Don Fry brazilnut@us.ibm.com From khc@pm.waw.pl Wed Jun 23 15:20:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 15:20:47 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NMKRgi004276 for ; Wed, 23 Jun 2004 15:20:28 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 748A7358; Thu, 24 Jun 2004 00:20:24 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 6AA74302D4; Thu, 24 Jun 2004 00:18:21 +0200 (CEST) To: dane@aiinet.com Cc: netdev@oss.sgi.com Subject: Re: [FYI PATCH] Ethernet over Cisco HDLC References: From: Krzysztof Halasa Date: Thu, 24 Jun 2004 00:18:21 +0200 In-Reply-To: (Dan Eble's message of "Wed, 23 Jun 2004 16:37:06 -0400 (EDT)") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6291 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 Dan Eble writes: > I don't expect this patch to apply to any recent versions of the kernel. > I'm posting it in case there is someone interested in porting it. If > someone has the time to comment on the locking during dev destruction, I > would appreciate receiving pointers. Any other comments are welcome too. > > [To Krzysztof Halasa: All my mail to your pm.waw address bounces. Is > there an alternate address I can use to contact you?] No (t yet). It should now work (looks like HELO name of your mail server isn't registered in DNS). > --- Old/include/linux/if.h 2004-06-23 13:59:58.000000000 -0400 > +++ New/include/linux/if.h 2004-06-23 16:19:07.000000000 -0400 > @@ -69,20 +69,22 @@ > #define IF_PROTO_CISCO 0x2002 /* Cisco HDLC protocol */ > #define IF_PROTO_FR 0x2003 /* Frame Relay protocol */ > #define IF_PROTO_FR_ADD_PVC 0x2004 /* Create FR PVC */ > #define IF_PROTO_FR_DEL_PVC 0x2005 /* Delete FR PVC */ > #define IF_PROTO_X25 0x2006 /* X.25 */ > #define IF_PROTO_HDLC_ETH 0x2007 /* raw HDLC, Ethernet emulation */ > #define IF_PROTO_FR_ADD_ETH_PVC 0x2008 /* Create FR Ethernet-bridged PVC */ > #define IF_PROTO_FR_DEL_ETH_PVC 0x2009 /* Delete FR Ethernet-bridged PVC */ > #define IF_PROTO_FR_PVC 0x200A /* for reading PVC status */ > #define IF_PROTO_FR_ETH_PVC 0x200B > +#define IF_PROTO_CISCO_ENABLE_PROTO 0x200C /* enable an encapsulated proto */ > +#define IF_PROTO_CISCO_DISABLE_PROTO 0x200D /* disable an encapsulated proto */ I wonder if we could merge IF_PROTO_FR_(ADD|DEL)_* and IF_PROTO_CISCO_*? It would get us the same sethdlc syntax and similar add/del code. -- Krzysztof Halasa, B*FH From cfriesen@nortelnetworks.com Wed Jun 23 16:16:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 16:16:31 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NNGRgi005536 for ; Wed, 23 Jun 2004 16:16:27 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5NNGJV05985; Wed, 23 Jun 2004 19:16:19 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALS0N2C; Wed, 23 Jun 2004 19:16:20 -0400 Message-ID: <40DA0F42.9060802@nortelnetworks.com> Date: Wed, 23 Jun 2004 19:16:18 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux kernel , netdev@oss.sgi.com Subject: BUG: kernel panic at startup, 2.6.7 on x86 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev I tried syncing with 2.6.7 bk version, compiled with my 2.6.5 config, installed, and rebooted. Everything was okay up to the point where it runs a script to set up my dsl connection. At that point I got the following on the console: "Starting adsl: Kernel panic: Aiee, killing interrupt handler! In interrupt handler -- not syncing." Unfortunately, that was all I got. Here's the output of lspci. Note, the linksys cards use the tulip driver. 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 16) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:08.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) 00:09.0 SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 03) 00:0b.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) 00:0d.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1) If you need any more information, just let me know and I'll see what I can do. Chris From random@72616e646f6d20323030342d30342d31360a.nosense.org Wed Jun 23 16:48:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 16:48:34 -0700 (PDT) Received: from nosense.org (216.cust9.sa.dsl.ozemail.com.au [210.84.232.216]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5NNmQgi009292 for ; Wed, 23 Jun 2004 16:48:30 -0700 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by nosense.org (Postfix) with SMTP id D90AE3F02A; Thu, 24 Jun 2004 09:18:19 +0930 (CST) Date: Thu, 24 Jun 2004 09:18:19 +0930 From: Mark Smith To: Alexey Kuznetsov Cc: netdev@oss.sgi.com Subject: Re: [RFC PATCH] Change "local" route table preference from 0 to 3fff, to permit send-to-self policy routing Message-Id: <20040624091819.3f73012d.random@72616e646f6d20323030342d30342d31360a.nosense.org> In-Reply-To: <20040618204529.GA3106@ms2.inr.ac.ru> References: <20040618182505.195d76ba.random@72616e646f6d20323030342d30342d31360a.nosense.org> <20040618204529.GA3106@ms2.inr.ac.ru> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Hi Alexey, On Sat, 19 Jun 2004 00:45:29 +0400 Alexey Kuznetsov wrote: Thanks for spending the time replying to me, I appreciate it. > Hello! > > > that problem. Something I'll look into further, unless somebody can tell > > me that having a host reply its own ARP requests, even when received over > > a real interface, isn't possible at all. > > Sigh, do not you think that making undelatable local rule with preference 0 > was an easy decision. This kills most of coolness of policy making yet. :-) > > Essentially, your patch becomes 100% legal after we kill the places > where we ask "Is X.X.X.X our local address?". This thing with arp is one > of many places when we have to do this to keep stack relatively coherent. > We have several places where we do lookup directly in local table bypassing > policy rules, because we just do not have enough information to look > in right place. > Are all those non-policy places where this "local" lookup occurs places where only local traffic related functions occur ie. functions like ARP ? Or, in other words, non-packet forwarding decision functions ? In these places, does it just jump to rule 0 ? If this is the case, would it be possible to modify them to jump to the specially designated "local" table, using some other method than "local" always being rule 0, allowing them to find out what the locally assigned addresses are, yet not relying on the "local" table being rule 0 ? > > kernel hacking, if there is a better way to change the "local" route table > > preference, I'm all ears. > > No, really. It is the best. Not made only as fool proof, because adding > almost any rule before local one shuts down networking completely. > I can see how it is important to prevent people from killing off their networking. On the other hand, I tend to take the position that if you don't know what you are doing, you shouldn't be playing with it :-) In this case, I think if you are "silly" enough to change the order of the local table lookup, you should be "smart" enough to know the consequences, and if necessary, develop a configuration to avoid them. However, if my suggested patch or requested functionality would create an internal inconsistency or operational flaw within the Linux networking stack, then obviously it wouldn't be the right thing to do. I certainly don't know enough to make that judgement. I'm sure you do :-) Thanks again for getting back to me. Regards, Mark. From chengjin@cs.caltech.edu Wed Jun 23 22:49:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 22:50:19 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O5nwgi019486 for ; Wed, 23 Jun 2004 22:49:58 -0700 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 69DC3DF259; Wed, 23 Jun 2004 22:49:57 -0700 (PDT) Received: by orchestra.cs.caltech.edu (Postfix, from userid 20269) id 87CEA9BC27; Wed, 23 Jun 2004 22:49:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by orchestra.cs.caltech.edu (Postfix) with ESMTP id 9976A9BC26; Wed, 23 Jun 2004 22:49:54 -0700 (PDT) Date: Wed, 23 Jun 2004 22:49:54 -0700 (PDT) From: Cheng Jin To: "netdev@oss.sgi.com" Cc: fast-support@cs.caltech.edu Subject: TCP receiver's window calculation problem In-Reply-To: <40D9BF6B.4050807@draigBrady.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Hi, We have been running some iperf experiments over long-latency high-capacity networks for protocol testing. We noticed a strange receiver's window limitation of 3,147,776 bytes even when the iperf server was setup to request 32 MB of socket buffer (for which kernel grants twice that). After doing printk with various window calculation functions at the receiver, we believe there may be a possible problem with tp->rcv_ssthresh calculation in __tcp_grow_window in tcp_input.c. With input parameters of tcp memory of 64 MB, a jumbo MTU (9000 bytes) setting at the receiver, which gives a skb_true_size of 16660 bytes, and a standard MTU (1500 byte) at the sender side that yields a skb_len of 1448 bytes. tp->rcv_ssthresh gets stuck at 3,148,472 (see the code segment below). Because the tcp receiver's window needs to be in multiple of mss (/1448 then *1448) and window scaling (>>10 and then <<10), the sender sees a limit of 3,147,776 bytes. I include an example code (stripped away the data structs and expanded whatever macros there are) that reproduces this problem. The function __tcp_grow_window itself may have problems for other combinations of input. #include #include typedef unsigned int __u32; static int __tcp_grow_window(__u32 rcv_ssthresh, __u32 tcp_full_space, __u32 skb_true_size, __u32 skb_len) { int truesize = skb_true_size*3/8; int window = tcp_full_space*3/8; while ( rcv_ssthresh <= window ) { if ( truesize <= skb_len ) return 2896; truesize >>= 1; window >>= 1; } return 0; } int main() { __u32 iperf_mem = 64*1024*1024; __u32 skb_true_size = 16660; __u32 skb_len = 1448; __u32 rcv_ssthresh = 3148472; int i, incr; for (i=0; i<1000; ++i) { incr = __tcp_grow_window(rcv_ssthresh, iperf_mem, skb_true_size, skb_len); printf("i=%d incr=%d\n", i, incr); } } Cheng -- Lab # 626 395 8820 From akpm@osdl.org Wed Jun 23 23:31:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 23:31:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O6Vggi020636 for ; Wed, 23 Jun 2004 23:31:42 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i5O6VUZ31243; Wed, 23 Jun 2004 23:31:30 -0700 Message-Id: <200406240631.i5O6VUZ31243@mail.osdl.org> Subject: [patch 2/4] fc.c warning fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Wed, 23 Jun 2004 23:30:34 -0700 X-archive-position: 6296 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 net/802/fc.c: In function `fc_header': net/802/fc.c:50: warning: 'fch' is used uninitialized in this function Signed-off-by: Andrew Morton --- 25-akpm/net/802/fc.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/802/fc.c~fc-warning-fix net/802/fc.c --- 25/net/802/fc.c~fc-warning-fix 2004-06-23 23:30:09.627735232 -0700 +++ 25-akpm/net/802/fc.c 2004-06-23 23:30:09.630734776 -0700 @@ -47,7 +47,7 @@ int fc_header(struct sk_buff *skb, struc */ if (type == ETH_P_IP || type == ETH_P_ARP) { - struct fcllc *fcllc=(struct fcllc *)(fch+1); + struct fcllc *fcllc; hdr_len = sizeof(struct fch_hdr) + sizeof(struct fcllc); fch = (struct fch_hdr *)skb_push(skb, hdr_len); _ From akpm@osdl.org Wed Jun 23 23:31:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 23:31:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O6Vjgi020637 for ; Wed, 23 Jun 2004 23:31:45 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i5O6VXZ31250; Wed, 23 Jun 2004 23:31:33 -0700 Message-Id: <200406240631.i5O6VXZ31250@mail.osdl.org> Subject: [patch 3/4] ip_fw_compat_masq.c build fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Wed, 23 Jun 2004 23:30:37 -0700 X-archive-position: 6297 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 net/ipv4/netfilter/ip_fw_compat_masq.c: In function `check_for_demasq': net/ipv4/netfilter/ip_fw_compat_masq.c:165: error: 'IP_OFFSET' undeclared (first use in this function) net/ipv4/netfilter/ip_fw_compat_masq.c:165: error: (Each undeclared identifier is reported only once net/ipv4/netfilter/ip_fw_compat_masq.c:165: error: for each function it appears in.) Signed-off-by: Andrew Morton --- 25-akpm/net/ipv4/netfilter/ip_fw_compat_masq.c | 1 + 1 files changed, 1 insertion(+) diff -puN net/ipv4/netfilter/ip_fw_compat_masq.c~ip_fw_compat_masq-build-fix net/ipv4/netfilter/ip_fw_compat_masq.c --- 25/net/ipv4/netfilter/ip_fw_compat_masq.c~ip_fw_compat_masq-build-fix 2004-06-23 23:30:10.094664248 -0700 +++ 25-akpm/net/ipv4/netfilter/ip_fw_compat_masq.c 2004-06-23 23:30:10.097663792 -0700 @@ -24,6 +24,7 @@ #include #include #include +#include #define ASSERT_READ_LOCK(x) MUST_BE_READ_LOCKED(&ip_conntrack_lock) #define ASSERT_WRITE_LOCK(x) MUST_BE_WRITE_LOCKED(&ip_conntrack_lock) _ From akpm@osdl.org Wed Jun 23 23:31:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 23:31:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O6Vegi020635 for ; Wed, 23 Jun 2004 23:31:40 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i5O6VSZ31238; Wed, 23 Jun 2004 23:31:28 -0700 Message-Id: <200406240631.i5O6VSZ31238@mail.osdl.org> Subject: [patch 1/4] tr.c warning fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Wed, 23 Jun 2004 23:30:31 -0700 X-archive-position: 6295 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 A few things popped up when using current gcc cvs. net/802/tr.c: In function `tr_header': net/802/tr.c:113: warning: 'trh' is used uninitialized in this function Signed-off-by: Andrew Morton --- 25-akpm/net/802/tr.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/802/tr.c~tr-warning-fixes net/802/tr.c --- 25/net/802/tr.c~tr-warning-fixes 2004-06-23 22:55:28.191161688 -0700 +++ 25-akpm/net/802/tr.c 2004-06-23 22:55:39.811395144 -0700 @@ -110,7 +110,7 @@ int tr_header(struct sk_buff *skb, struc */ if (type == ETH_P_IP || type == ETH_P_IPV6 || type == ETH_P_ARP) { - struct trllc *trllc=(struct trllc *)(trh+1); + struct trllc *trllc; hdr_len = sizeof(struct trh_hdr) + sizeof(struct trllc); trh = (struct trh_hdr *)skb_push(skb, hdr_len); _ From akpm@osdl.org Wed Jun 23 23:31:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Jun 2004 23:31:54 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O6Vmgi020652 for ; Wed, 23 Jun 2004 23:31:48 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i5O6VaZ31258; Wed, 23 Jun 2004 23:31:36 -0700 Message-Id: <200406240631.i5O6VaZ31258@mail.osdl.org> Subject: [patch 4/4] pkt_sched.h warning fixes To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Wed, 23 Jun 2004 23:30:40 -0700 X-archive-position: 6298 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 net/sched/police.c: In function `tcf_act_police': net/sched/police.c:324: warning: statement with no effect net/sched/police.c: In function `tcf_police': net/sched/police.c:526: warning: statement with no effect net/sched/sch_htb.c: In function `htb_debug_dump': net/sched/sch_htb.c:370: warning: statement with no effect net/sched/sch_htb.c: In function `htb_charge_class': net/sched/sch_htb.c:810: warning: statement with no effect net/sched/sch_htb.c: In function `htb_do_events': net/sched/sch_htb.c:881: warning: statement with no effect net/sched/sch_red.c: In function `red_enqueue': net/sched/sch_red.c:192: warning: statement with no effect net/sched/sch_gred.c: In function `gred_enqueue': net/sched/sch_gred.c:158: warning: statement with no effect net/sched/sch_gred.c: In function `gred_dump': net/sched/sch_gred.c:554: warning: statement with no effect net/sched/sch_tbf.c: In function `tbf_dequeue': net/sched/sch_tbf.c:210: warning: statement with no effect Signed-off-by: Andrew Morton --- 25-akpm/net/sched/police.c | 4 ++-- 25-akpm/net/sched/sch_gred.c | 4 ++-- 25-akpm/net/sched/sch_htb.c | 6 +++--- 25-akpm/net/sched/sch_red.c | 2 +- 25-akpm/net/sched/sch_tbf.c | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff -puN net/sched/police.c~pkt_sched-warning-fixes net/sched/police.c --- 25/net/sched/police.c~pkt_sched-warning-fixes 2004-06-23 23:30:10.482605272 -0700 +++ 25-akpm/net/sched/police.c 2004-06-23 23:30:10.491603904 -0700 @@ -321,7 +321,7 @@ int tcf_act_police(struct sk_buff **pskb PSCHED_GET_TIME(now); - toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst, 0); + toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst, (void)0); if (p->P_tab) { ptoks = toks + p->ptoks; @@ -523,7 +523,7 @@ int tcf_police(struct sk_buff *skb, stru PSCHED_GET_TIME(now); - toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst, 0); + toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst, (void)0); if (p->P_tab) { ptoks = toks + p->ptoks; diff -puN net/sched/sch_gred.c~pkt_sched-warning-fixes net/sched/sch_gred.c --- 25/net/sched/sch_gred.c~pkt_sched-warning-fixes 2004-06-23 23:30:10.483605120 -0700 +++ 25-akpm/net/sched/sch_gred.c 2004-06-23 23:30:10.492603752 -0700 @@ -155,7 +155,7 @@ gred_enqueue(struct sk_buff *skb, struct if (!PSCHED_IS_PASTPERFECT(q->qidlestart)) { long us_idle; PSCHED_GET_TIME(now); - us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, 0); + us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, (void)0); PSCHED_SET_PASTPERFECT(q->qidlestart); q->qave >>= q->Stab[(us_idle>>q->Scell_log)&0xFF]; @@ -551,7 +551,7 @@ static int gred_dump(struct Qdisc *sch, long idle; psched_time_t now; PSCHED_GET_TIME(now); - idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, 0); + idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, (void)0); qave = q->qave >> q->Stab[(idle>>q->Scell_log)&0xFF]; dst->qave = qave >> q->Wlog; diff -puN net/sched/sch_htb.c~pkt_sched-warning-fixes net/sched/sch_htb.c --- 25/net/sched/sch_htb.c~pkt_sched-warning-fixes 2004-06-23 23:30:10.485604816 -0700 +++ 25-akpm/net/sched/sch_htb.c 2004-06-23 23:30:10.493603600 -0700 @@ -367,7 +367,7 @@ static void htb_debug_dump (struct htb_s struct list_head *l; list_for_each (l,q->hash+i) { struct htb_class *cl = list_entry(l,struct htb_class,hlist); - long diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, 0); + long diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, (void)0); printk(KERN_DEBUG "htb*c%x m=%d t=%ld c=%ld pq=%lu df=%ld ql=%d " "pa=%x f:", cl->classid,cl->cmode,cl->tokens,cl->ctokens, @@ -807,7 +807,7 @@ static void htb_charge_class(struct htb_ while (cl) { HTB_CHCL(cl); - diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, 0); + diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, (void)0); #ifdef HTB_DEBUG if (diff > cl->mbuffer || diff < 0 || PSCHED_TLESS(q->now, cl->t_c)) { if (net_ratelimit()) @@ -878,7 +878,7 @@ static long htb_do_events(struct htb_sch return cl->pq_key - q->jiffies; } htb_safe_rb_erase(p,q->wait_pq+level); - diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, 0); + diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, (void)0); #ifdef HTB_DEBUG if (diff > cl->mbuffer || diff < 0 || PSCHED_TLESS(q->now, cl->t_c)) { if (net_ratelimit()) diff -puN net/sched/sch_red.c~pkt_sched-warning-fixes net/sched/sch_red.c --- 25/net/sched/sch_red.c~pkt_sched-warning-fixes 2004-06-23 23:30:10.486604664 -0700 +++ 25-akpm/net/sched/sch_red.c 2004-06-23 23:30:10.494603448 -0700 @@ -189,7 +189,7 @@ red_enqueue(struct sk_buff *skb, struct int shift; PSCHED_GET_TIME(now); - us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, 0); + us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, (void)0); PSCHED_SET_PASTPERFECT(q->qidlestart); /* diff -puN net/sched/sch_tbf.c~pkt_sched-warning-fixes net/sched/sch_tbf.c --- 25/net/sched/sch_tbf.c~pkt_sched-warning-fixes 2004-06-23 23:30:10.488604360 -0700 +++ 25-akpm/net/sched/sch_tbf.c 2004-06-23 23:30:10.494603448 -0700 @@ -207,7 +207,7 @@ static struct sk_buff *tbf_dequeue(struc PSCHED_GET_TIME(now); - toks = PSCHED_TDIFF_SAFE(now, q->t_c, q->buffer, 0); + toks = PSCHED_TDIFF_SAFE(now, q->t_c, q->buffer, (void)0); if (q->P_tab) { ptoks = toks + q->ptokens; _ From info@lineo.com Thu Jun 24 00:44:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 00:44:54 -0700 (PDT) Received: from mail.lineo.com (apollo.lineo.com [64.50.107.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O7iqgi028897 for ; Thu, 24 Jun 2004 00:44:52 -0700 Received: (qmail 15909 invoked by uid 110); 24 Jun 2004 07:44:51 -0000 Delivered-To: info@lineo.com Message-ID: <20040624074451.15908.qmail@lineo.com> Date: 24 Jun 2004 07:44:51 -0000 From: info@lineo.com To: netdev@oss.sgi.com Subject: [Auto-Reply] Auslaenderanteile in Schweizer Gefaengnissen MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: qmail-reply (by qmail-ldap) Precedence: junk X-archive-position: 6299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: info@lineo.com Precedence: bulk X-list: netdev This account has been disabled. Contact Metrowerks for more information. From akpm@osdl.org Thu Jun 24 01:10:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 01:11:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5O8Aegi006182 for ; Thu, 24 Jun 2004 01:10:40 -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 i5O8AZZ12314 for ; Thu, 24 Jun 2004 01:10:35 -0700 Date: Thu, 24 Jun 2004 01:09:38 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: fib_hash.c:fn_hash() Message-Id: <20040624010938.55f90500.akpm@osdl.org> 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: 6300 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 Current gcc CVS emits a memmove() when compiling this function, and the kernel link fails. The gcc guys are being rude about it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16172 From P@draigBrady.com Thu Jun 24 03:36:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 03:36:40 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OAaagi011534 for ; Thu, 24 Jun 2004 03:36:37 -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 i5OAaOOC012717; Thu, 24 Jun 2004 11:36:24 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40DAAEA8.7050105@draigBrady.com> Date: Thu, 24 Jun 2004 11:36:24 +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: Chris Leech CC: e1000-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [E1000-devel] e1000 jumbo problems References: <40D883C2.7010106@draigBrady.com> <40D9BF6B.4050807@draigBrady.com> <41b516cb040623114825a9c555@mail.gmail.com> In-Reply-To: <41b516cb040623114825a9c555@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i5OAaOOC012717 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5OAaagi011534 X-archive-position: 6301 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 Chris Leech wrote: >>>Another related issue, is that the driver uses 4KiB buffers >>>for MTUs in the 1500 -> 2000 range which seems a bit silly. >>>Any particular reason for that? > > > It is wasteful, but does anyone actually use an MTU in the range of > 1501 - 2030? It seems silly to me to go with a non-standard frame > size, but not go up to something that might give you a performance > benefit (9k). I'm seeing it with MPLS in some configs. MPLS labels are just prepended onto ethernet frames giving frames up to 1546 bytes. Using 4KiB frames for this situation is wasteful of memory but more importantly for my application it has a noticeable impact on receive performance. >>I changed the driver to use 2KiB buffers for frames in the >>1518 -> 2048 range (BSEX=0, LPE=1). This breaks however >>as packets are not dropped that are larger than the max specified? >>Instead they're scribbled into memory causing a lockup after a while. > > > That sounds right, if you actually got the RCTL register set > correctly. In e1000_setup_rctl the adapter->rx_buffer_len is used to > set that register, and it's currently written to only set LPE if the > buffer size is bigger than 2k (thus, why 4k buffers are used even when > the MTU is in the 1501 - 2030 range). To use 2k buffers for slightly > large frames, you'd want some new flag in the adapter for LPE (or > check netdev->mtu I guess) and do something like: rctl |= > E1000_RCTL_SZ_2048 | E1000_RCTL_LPE yep, that's what I did. > e1000 devices don't have a programmable MTU for receive filtering, > they drop anything larger than 1518 unless LPE (long packet enable) is > set. If LPE is set they accept anything that fits in the FIFO and has > a valid FCS. thanks for that. What I'm noticing now is the same thing happens with the official driver (5.2.52 or 5.2.30.1). I.E. set the MTU to 4000 for e.g., then send in frames larger than 4096 and they're accepted? Doing this for a while causes mem to get corrupted. > An MTU setting needs to be valid across your ethernet, why is the > e1000 receiving a frame larger than the MTU? (jabber should be rare) > But, if the length of receive buffers matches what was set in RCTL, > larger than expected valid frames will spill over to the next buffer > and be dropped in the driver without corrupting memory. Are the buffers in contiguous mem? What happens for the last buffer? >>I noticed in e1000_change_mtu() that adapter->hw.max_frame_size >>is only set after e1000_down();e1000_up(); Is that correct? > > There might be a slight race there (I'll think about it some more), > but it's not something that would cause memory corruption. > hw.max_frame_size is only used in a software workaround for 82543 > based copper gigabit cards (vendor:device 8086:1004) when paired with > certain link partners. fair enough. > >>Are there any anwsers for the general questions I had even? >> >>1. Is there a public dev tree available for the e1000 driver? > > No, the best source base to work from is what is in the 2.6 kernel > tree (or Jeff's net-drivers tree). We keep that as up to date as > possible, and it's always fairly close to our internal development > sources. > >>2. Are there programming docs for the various GigE chipsets? > > Not publicly available at this time. thanks a million, Pdraig. From ak@suse.de Thu Jun 24 04:32:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 04:32:38 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OBWHgi017165 for ; Thu, 24 Jun 2004 04:32:18 -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 96DA17A4BB0; Thu, 24 Jun 2004 12:39:05 +0200 (CEST) Date: Thu, 24 Jun 2004 12:39:05 +0200 From: Andi Kleen To: Andrew Morton Cc: netdev@oss.sgi.com Subject: Re: fib_hash.c:fn_hash() Message-ID: <20040624103905.GB16727@wotan.suse.de> References: <20040624010938.55f90500.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624010938.55f90500.akpm@osdl.org> X-archive-position: 6302 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 Thu, Jun 24, 2004 at 01:09:38AM -0700, Andrew Morton wrote: > > Current gcc CVS emits a memmove() when compiling this function, and the > kernel link fails. It's just an i386 bug. Other architectures have a proper out of line memmove. I would suggest to just not define __HAVE_ARCH_MEMMOVE, then lib/string.c will do the right thing. BTW if we don't want to supply these functions we should change the kernel to compile with -ffreestanding. But so far at least the common ports are good enough at that now that it isn't needed. -Andi Here's a patch: Or perhaps it would be better to just remove this completely from asm/string.h, since I can see no sane reason to inline memmove(). That would make the kernel smaller. diff -u linux/include/asm-i386/string.h-o linux/include/asm-i386/string.h --- linux/include/asm-i386/string.h-o 2004-03-21 21:11:56.000000000 +0100 +++ linux/include/asm-i386/string.h 2004-06-24 12:38:25.000000000 +0200 @@ -293,7 +293,7 @@ memcpy(x, y, sizeof(*(x))); \ }) -#define __HAVE_ARCH_MEMMOVE +#ifndef IN_STRING_C static inline void * memmove(void * dest,const void * src, size_t n) { int d0, d1, d2; @@ -312,6 +312,7 @@ :"memory"); return dest; } +#endif #define memcmp __builtin_memcmp From herbert@gondor.apana.org.au Thu Jun 24 05:36:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 05:36:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OCaVgi019863 for ; Thu, 24 Jun 2004 05:36: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 1BdTSb-0007Mp-00; Thu, 24 Jun 2004 22:36:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BdTSV-0000MG-00; Thu, 24 Jun 2004 22:36:03 +1000 Date: Thu, 24 Jun 2004 22:36:03 +1000 To: agruen@suse.de, "David S. Miller" , netdev@oss.sgi.com Subject: [NAT-T] NON-IKE encapsulation Message-ID: <20040624123603.GA1241@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6303 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 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: I'm having trouble understanding why we need to increase alen by two bytes for NON-IKE. As far as I can see it's adding two bytes of random data to the end of the packet. Is there something obvious that I'm missing? If not then we'll need this 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 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/esp4.c 1.41 vs edited ===== --- 1.41/net/ipv4/esp4.c 2004-06-23 06:53:57 +10:00 +++ edited/net/ipv4/esp4.c 2004-06-24 22:26:50 +10:00 @@ -106,7 +106,6 @@ udpdata32 = (u32*)(uh+1); udpdata32[0] = udpdata32[1] = 0; esph = (struct ip_esp_hdr*)(udpdata32+2); - alen += 2; top_iph->protocol = IPPROTO_UDP; break; default: @@ -149,7 +148,6 @@ udpdata32 = (u32*)(uh+1); udpdata32[0] = udpdata32[1] = 0; esph = (struct ip_esp_hdr*)(udpdata32+2); - alen += 2; top_iph->protocol = IPPROTO_UDP; break; default: --OgqxwSJOaUobr8KG-- From DanE@aiinet.com Thu Jun 24 07:24:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 07:24:44 -0700 (PDT) Received: from AIMAIL1.ai.aiinet.com (ai181-15.aiinet.com [205.245.181.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OEOPgi023176 for ; Thu, 24 Jun 2004 07:24:27 -0700 Received: by AIMAIL1.ai.aiinet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 10:24:27 -0400 Message-ID: From: "Eble, Dan" To: "'Krzysztof Halasa'" Cc: netdev@oss.sgi.com Subject: RE: [FYI PATCH] Ethernet over Cisco HDLC Date: Thu, 24 Jun 2004 10:24:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 6304 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 > I wonder if we could merge IF_PROTO_FR_(ADD|DEL)_* and > IF_PROTO_CISCO_*? > It would get us the same sethdlc syntax and similar add/del code. > -- > Krzysztof Halasa, B*FH Are you sure that is a good idea? Using separate numbers for Cisco and FR is a safeguard against unwittingly creating an FR PVC with "sethdlc cisco proto ether ... ". Or are you suggesting to merge the sethdlc syntax too? From jgarzik@pobox.com Thu Jun 24 08:39:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 08:39:44 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OFdegi028406 for ; Thu, 24 Jun 2004 08:39:41 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BdWKC-0007vC-1V; Thu, 24 Jun 2004 16:39:40 +0100 Message-ID: <40DAF5AB.60108@pobox.com> Date: Thu, 24 Jun 2004 11:39:23 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: fib_hash.c:fn_hash() References: <20040624010938.55f90500.akpm@osdl.org> <20040624103905.GB16727@wotan.suse.de> In-Reply-To: <20040624103905.GB16727@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6305 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 Andi Kleen wrote: > BTW if we don't want to supply these functions we should change > the kernel to compile with -ffreestanding. But so far at least > the common ports are good enough at that now that it isn't needed. Agreed... From bwindle@fint.org Thu Jun 24 10:02:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 10:02:23 -0700 (PDT) Received: from ispmxmta05-srv.alltel.net (ispmxmta05-srv.alltel.net [166.102.165.166]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OH2Jgi030973 for ; Thu, 24 Jun 2004 10:02:19 -0700 Received: from morpheus ([151.213.165.79]) by ispmxmta05-srv.alltel.net with ESMTP id <20040624170213.KPXS23097.ispmxmta05-srv.alltel.net@morpheus> for ; Thu, 24 Jun 2004 12:02:13 -0500 Received: from bwindle (helo=localhost) by morpheus with local-esmtp (Exim 3.36 #1 (Debian)) id 1BdXc4-0000Po-00 for ; Thu, 24 Jun 2004 13:02:12 -0400 Date: Thu, 24 Jun 2004 13:02:12 -0400 (EDT) From: Burton Windle X-X-Sender: bwindle@morpheus To: netdev@oss.sgi.com Subject: Trivial patch for printk in tcp_input.c Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-499955320-1088096532=:921" X-archive-position: 6306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bwindle@fint.org Precedence: bulk X-list: netdev 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. --8323328-499955320-1088096532=:921 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a trivial patch to add a newline at the end of a printk in tcp_input.c. patch is against 2.6.7. Without this patch, the output of the printk in question looks like this: tcp_parse_options: Illegal window scaling value 255 >14 received.tcp_parse_options: Illegal window scaling value 255 >14 received.tcp_parse_options: Illegal window scaling value 255 >14 received.tcp_parse_options: Illegal window scaling value 255 >14 received. It might be nice if this printk told us where the packet came from, but I'll save that for another patch. -- Burton Windle bwindle@fint.org --8323328-499955320-1088096532=:921 Content-Type: TEXT/plain; charset=US-ASCII; name="tcp_input_printk_fix.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: fix newline in printk Content-Disposition: attachment; filename="tcp_input_printk_fix.diff" LS0tIGxpbnV4L25ldC9pcHY0L3RjcF9pbnB1dC5jCTIwMDQtMDYtMTYgMTE6 MzM6MTYuMDAwMDAwMDAwIC0wNDAwDQorKysgbGludXgtYncvbmV0L2lwdjQv dGNwX2lucHV0LmMJMjAwNC0wNi0yNCAxMjo1MzowNi4wMDAwMDAwMDAgLTA0 MDANCkBAIC0yOTE5LDcgKzI5MTksNyBAQA0KIAkJCQkJCQlpZih0cC0+c25k X3dzY2FsZSA+IDE0KSB7DQogCQkJCQkJCQlpZihuZXRfcmF0ZWxpbWl0KCkp DQogCQkJCQkJCQkJcHJpbnRrKCJ0Y3BfcGFyc2Vfb3B0aW9uczogSWxsZWdh bCB3aW5kb3cgIg0KLQkJCQkJCQkJCSAgICAgICAic2NhbGluZyB2YWx1ZSAl ZCA+MTQgcmVjZWl2ZWQuIiwNCisJCQkJCQkJCQkgICAgICAgInNjYWxpbmcg dmFsdWUgJWQgPjE0IHJlY2VpdmVkLlxuIiwNCiAJCQkJCQkJCQkgICAgICAg dHAtPnNuZF93c2NhbGUpOw0KIAkJCQkJCQkJdHAtPnNuZF93c2NhbGUgPSAx NDsNCiAJCQkJCQkJfQ0K --8323328-499955320-1088096532=:921-- From vincent-perrier@club-internet.fr Thu Jun 24 10:28:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 10:28:36 -0700 (PDT) Received: from relay-6m.club-internet.fr (relay-6m.club-internet.fr [194.158.104.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OHSWgi031803 for ; Thu, 24 Jun 2004 10:28:33 -0700 Received: from club-internet.fr (l07v-13-117.d2.club-internet.fr [62.34.198.117]) by relay-6m.club-internet.fr (Postfix) with ESMTP id 398BF25623 for ; Thu, 24 Jun 2004 19:28:31 +0200 (CEST) Message-ID: <40DB0F54.6020502@club-internet.fr> Date: Thu, 24 Jun 2004 19:28:52 +0200 From: Vincent Perrier User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.6) Gecko/20040122 X-Accept-Language: fr, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: htb vs hfsc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vincent-perrier@club-internet.fr Precedence: bulk X-list: netdev HTB versus HFSC, both qdisc offer the same kind of service, if you want to see comparative test results, go to http://www.rawsoft.org at the line "TEST RESULTS" you will find the results of 2 tests, the sharing and the burst of high priority. You will also see that both qdiscs are good. From jheffner@psc.edu Thu Jun 24 10:43:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 10:43:39 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OHhYgi032393 for ; Thu, 24 Jun 2004 10:43:35 -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 i5OHhSbk015993 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Jun 2004 13:43:28 -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 i5OHhRhT029806; Thu, 24 Jun 2004 13:43:27 -0400 (EDT) Date: Thu, 24 Jun 2004 13:43:27 -0400 (EDT) From: John Heffner To: Cheng Jin cc: "netdev@oss.sgi.com" , Subject: Re: TCP receiver's window calculation problem In-Reply-To: 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: 6308 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 I've run in to this problem, too. This code prevents advertising more rcvbuf space than you are likely to need. This is good for something like an X11 connection, but obviously very bad for the bulk transfer mixed MTU case. Apparently some drivers use multiple packet buffer sizes which helps, but at least e1000 and sk98lin do not. If you don't want to overrun the rcvbuf bounds, then the only other recourse is to coalesce packets, which works well but is pretty expensive. This will happen already if you take out the rcv_ssthresh bound. I think the most desirable answer is to not have a hard per-connection memory bound, but this is problematic because of denial-of-service conerns. -John On Wed, 23 Jun 2004, Cheng Jin wrote: > > Hi, > > We have been running some iperf experiments over long-latency > high-capacity networks for protocol testing. We noticed a strange > receiver's window limitation of 3,147,776 bytes even when the iperf > server was setup to request 32 MB of socket buffer (for which kernel > grants twice that). > > After doing printk with various window calculation functions at the > receiver, we believe there may be a possible problem with > tp->rcv_ssthresh calculation in __tcp_grow_window in tcp_input.c. > > With input parameters of tcp memory of 64 MB, a jumbo MTU (9000 bytes) > setting at the receiver, which gives a skb_true_size of 16660 bytes, and a > standard MTU (1500 byte) at the sender side that yields a skb_len of 1448 > bytes. tp->rcv_ssthresh gets stuck at 3,148,472 (see the code segment > below). Because the tcp receiver's window needs to be in multiple of mss > (/1448 then *1448) and window scaling (>>10 and then <<10), the sender sees > a limit of 3,147,776 bytes. > > I include an example code (stripped away the data structs and expanded > whatever macros there are) that reproduces this problem. The function > __tcp_grow_window itself may have problems for other combinations of > input. > > #include > #include > > typedef unsigned int __u32; > > static int > __tcp_grow_window(__u32 rcv_ssthresh, __u32 tcp_full_space, > __u32 skb_true_size, __u32 skb_len) > { > int truesize = skb_true_size*3/8; > int window = tcp_full_space*3/8; > > while ( rcv_ssthresh <= window ) { > if ( truesize <= skb_len ) > return 2896; > > truesize >>= 1; > window >>= 1; > } > return 0; > } > > > int main() > { > > __u32 iperf_mem = 64*1024*1024; > __u32 skb_true_size = 16660; > __u32 skb_len = 1448; > __u32 rcv_ssthresh = 3148472; > > int i, incr; > > for (i=0; i<1000; ++i) > { > incr = __tcp_grow_window(rcv_ssthresh, iperf_mem, skb_true_size, skb_len); > printf("i=%d incr=%d\n", i, incr); > } > } > > > Cheng > > -- > Lab # 626 395 8820 > > From chengjin@cs.caltech.edu Thu Jun 24 12:18:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:18:26 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJINgi002761 for ; Thu, 24 Jun 2004 12:18:23 -0700 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 5C5B4DF2A2; Thu, 24 Jun 2004 12:18:22 -0700 (PDT) Received: by orchestra.cs.caltech.edu (Postfix, from userid 20269) id 5AEDC9BC27; Thu, 24 Jun 2004 12:18:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by orchestra.cs.caltech.edu (Postfix) with ESMTP id 680F39BC26; Thu, 24 Jun 2004 12:18:19 -0700 (PDT) Date: Thu, 24 Jun 2004 12:18:19 -0700 (PDT) From: Cheng Jin To: John Heffner Cc: "netdev@oss.sgi.com" , "fast-support@cs.caltech.edu" Subject: Re: TCP receiver's window calculation problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Hi, John, Thanks for confirming this problem. > I've run in to this problem, too. This code prevents advertising more > rcvbuf space than you are likely to need. This is good for something like > an X11 connection, but obviously very bad for the bulk transfer mixed MTU I would think this is already taken care of at the sender by application limited cwnd so cwnd wouldn't increase beyond what is being actually used. > I think the most desirable answer is to not have a hard per-connection > memory bound, but this is problematic because of denial-of-service > conerns. I think having a default limit on tcp memory is acceptable to prevent DoS, but when a user increases the memory limit by explicitly setting tcp_rmem, that should take effect. The code itself shouldnt pose any limit like it does now. Actually, I am not clear what that window-calculation algorithm is. Is it recommended by some RFC? Cheng From khc@pm.waw.pl Thu Jun 24 12:26:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:26:49 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJQjgi006415 for ; Thu, 24 Jun 2004 12:26:46 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 518C6366; Thu, 24 Jun 2004 21:26:40 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id AA8A1302D4; Thu, 24 Jun 2004 17:32:24 +0200 (CEST) To: "Eble, Dan" Cc: netdev@oss.sgi.com Subject: Re: [FYI PATCH] Ethernet over Cisco HDLC References: From: Krzysztof Halasa Date: Thu, 24 Jun 2004 17:32:24 +0200 In-Reply-To: (Dan Eble's message of "Thu, 24 Jun 2004 10:24:26 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6311 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 "Eble, Dan" writes: > Are you sure that is a good idea? Using separate numbers for Cisco and FR > is a safeguard against unwittingly creating an FR PVC with "sethdlc cisco > proto ether ... ". Or are you suggesting to merge the sethdlc syntax too? Almost. FR has DLCI, Cisco HDLC doesn't. This would result in small syntax and code differences. I have to investigate this a little further. For 2.6 I'd go with ~ your patch. -- Krzysztof Halasa, B*FH From jheffner@psc.edu Thu Jun 24 12:26:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:26:32 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJQUgi006299 for ; Thu, 24 Jun 2004 12:26: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 i5OJQRbk018172 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Jun 2004 15:26:28 -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 i5OJQRhT001284; Thu, 24 Jun 2004 15:26:27 -0400 (EDT) Date: Thu, 24 Jun 2004 15:26:27 -0400 (EDT) From: John Heffner To: Cheng Jin cc: "netdev@oss.sgi.com" , "fast-support@cs.caltech.edu" Subject: Re: TCP receiver's window calculation problem In-Reply-To: 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: 6310 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 On Thu, 24 Jun 2004, Cheng Jin wrote: > I think having a default limit on tcp memory is acceptable to prevent DoS, > but when a user increases the memory limit by explicitly setting tcp_rmem, > that should take effect. The code itself shouldnt pose any limit like it > does now. The core of the problem is that you are describing a truesize of each skb at about 16k, but each of those only contains < 1500 bytes of payload. You are wasting 90% of your socket memory. Announcing a 3 MB window with a 30 MB socket buffer is the right thing to do, from a certain point of view. OTOH, it kills performance. > Actually, I am not clear what that window-calculation algorithm is. Is it > recommended by some RFC? No, it's not standard. I'm not sure who wrote this code. -John From stingray@stingr.net Thu Jun 24 12:40:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:40:47 -0700 (PDT) Received: from stingr.net (stingr.net [212.193.32.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJefgi007215 for ; Thu, 24 Jun 2004 12:40:42 -0700 Received: by stingr.net (Postfix, from userid 1000) id 1688B9F61C; Thu, 24 Jun 2004 23:40:39 +0400 (MSD) Date: Thu, 24 Jun 2004 23:40:39 +0400 From: Paul P Komkoff Jr To: Linux Kernel Mailing List , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [RFC] How to implement wccp over gre tunnel ? Message-ID: <20040624194039.GA19574@stingr.net> Mail-Followup-To: Linux Kernel Mailing List , linux-net@vger.kernel.org, netdev@oss.sgi.com 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-archive-position: 6312 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 Hi! Currently my goal is to make squid + wccp configuration working out-of-the box. Ideally - without any extra modules. I suspect that to be accepted into mainline implementation of it must be as clean as possible :) Currently, most wccp configurations are working with this module: http://www.squid-cache.org/WCCP-support/Linux/ip_wccp.c For things to work we need to get stream of packets redirected from router, as standard non-encapsulated packets, and feed it into ip filter. The problem is router-side wccp algorithm. Instead of doing simple gre encapsulation, wccp does the following: 1. Change protocol from ETH_P_IP (0x0800) to 0x883E 2. if it is wccp2, then add 4 bytes of flags So, on receiver side, we need to do reverse thing. Module I mentioned earlier inspects all GRE protocol packets, checking bytes where proto value of it's payload (e.g. encapsulated packet) reside, and if it's 0x883E, then it strips gre header, strips wccp2 flags (if exist), and requeue packets on any suitable interface (if I understood that skb->dst = NULL correctly). This works, actually, but (a) we cannot control local-remote of gre tunnel, (b) we cannot determine is that packet from router or from network itself and (c) when we have 2 or more routers turned to different ip's on one host it is complete mess. When we, instead of using this module, properly configuring gre tunnel between host and router, we starting getting packets with proto 0x883E and probably (for wccp2) 4 extra bytes after proto field. Of course this traffic is useless. I am thinking about making decapsulated AND reconstructed (wrt proto and wccp2 flags) packets appear on gre tunnel interface. This goal can be implemented by following approaches: 1. Hack ip_gre.c. Add some sysctl to it, or maybe add possibility to set specific flags on individual interfaces. When flag is set - ip_gre rx routine parses wccp packets and converts it to acceptable ip. 2. Write module, with 0x883E protocol handler inside. That rx routine should replace 0x883E with P_IP, check and strip v2 flags, and requeue packet on interface where it arrived first. This can be complemented with some settable flag specifying on which interfaces it should do that translation. What do you think? Which way I should do? P.S. IIRC approach (1) is implemented inf FreeBSD. -- 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@redhat.com Thu Jun 24 12:42:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:42:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJgdgi007553 for ; Thu, 24 Jun 2004 12:42:42 -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 i5OJgae1017456; Thu, 24 Jun 2004 15:42: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 i5OJga008718; Thu, 24 Jun 2004 15:42: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 i5OJgEH7001332; Thu, 24 Jun 2004 15:42:14 -0400 Date: Thu, 24 Jun 2004 12:42:34 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [patch 1/4] tr.c warning fix Message-Id: <20040624124234.3f2dab98.davem@redhat.com> In-Reply-To: <200406240631.i5O6VSZ31238@mail.osdl.org> References: <200406240631.i5O6VSZ31238@mail.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: 6313 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 Wed, 23 Jun 2004 23:30:31 -0700 akpm@osdl.org wrote: > A few things popped up when using current gcc cvs. > > net/802/tr.c: In function `tr_header': > net/802/tr.c:113: warning: 'trh' is used uninitialized in this function > > Signed-off-by: Andrew Morton Applied. From davem@redhat.com Thu Jun 24 12:43:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:43:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJhKgi007879 for ; Thu, 24 Jun 2004 12:43:20 -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 i5OJhEe1017661; Thu, 24 Jun 2004 15:43:14 -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 i5OJhE009031; Thu, 24 Jun 2004 15:43:14 -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 i5OJgpGM002007; Thu, 24 Jun 2004 15:42:52 -0400 Date: Thu, 24 Jun 2004 12:43:11 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [patch 2/4] fc.c warning fix Message-Id: <20040624124311.61264cbb.davem@redhat.com> In-Reply-To: <200406240631.i5O6VUZ31243@mail.osdl.org> References: <200406240631.i5O6VUZ31243@mail.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: 6314 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 Applied. From davem@redhat.com Thu Jun 24 12:44:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:44:02 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJi0gi008208 for ; Thu, 24 Jun 2004 12:44: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 i5OJhve1017832; Thu, 24 Jun 2004 15:43:57 -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 i5OJhv009203; Thu, 24 Jun 2004 15:43:57 -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 i5OJhZgG002443; Thu, 24 Jun 2004 15:43:35 -0400 Date: Thu, 24 Jun 2004 12:43:55 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [patch 3/4] ip_fw_compat_masq.c build fix Message-Id: <20040624124355.5c630b3b.davem@redhat.com> In-Reply-To: <200406240631.i5O6VXZ31250@mail.osdl.org> References: <200406240631.i5O6VXZ31250@mail.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: 6315 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 Applied. From davem@redhat.com Thu Jun 24 12:45:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:45:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJjlgi008548 for ; Thu, 24 Jun 2004 12:45:47 -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 i5OJjhe1018336; Thu, 24 Jun 2004 15:45:43 -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 i5OJjh009563; Thu, 24 Jun 2004 15:45:43 -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 i5OJjKuv003340; Thu, 24 Jun 2004 15:45:21 -0400 Date: Thu, 24 Jun 2004 12:45:41 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [patch 4/4] pkt_sched.h warning fixes Message-Id: <20040624124541.062d94e0.davem@redhat.com> In-Reply-To: <200406240631.i5O6VaZ31258@mail.osdl.org> References: <200406240631.i5O6VaZ31258@mail.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: 6316 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 I guess that's the cleanest way to deal with that for now. Applied. Thanks. From davem@redhat.com Thu Jun 24 12:47:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 12:47:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OJl5gi009375 for ; Thu, 24 Jun 2004 12:47:06 -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 i5OJkve1018752; Thu, 24 Jun 2004 15:46:57 -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 i5OJkv010072; Thu, 24 Jun 2004 15:46:57 -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 i5OJkY8C003984; Thu, 24 Jun 2004 15:46:35 -0400 Date: Thu, 24 Jun 2004 12:46:54 -0700 From: "David S. Miller" To: Herbert Xu Cc: agruen@suse.de, netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-Id: <20040624124654.36b31815.davem@redhat.com> In-Reply-To: <20040624123603.GA1241@gondor.apana.org.au> References: <20040624123603.GA1241@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: 6317 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, 24 Jun 2004 22:36:03 +1000 Herbert Xu wrote: > I'm having trouble understanding why we need to increase alen by > two bytes for NON-IKE. As far as I can see it's adding two bytes > of random data to the end of the packet. Is there something > obvious that I'm missing? It is intentional as far as I remember. If it's any other length, then the other side implementing this non-IKE encap stuff won't accept the packet, it must be that length. From mxrucwjlcmiw@msn.com Thu Jun 24 14:23:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 14:23:59 -0700 (PDT) Received: from oss.sgi.com (kptawpf@[200.72.173.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OLNcgi014536 for ; Thu, 24 Jun 2004 14:23:40 -0700 Message-Id: <200406242123.i5OLNcgi014536@oss.sgi.com> From: mxrucwjlcmiw@msn.com To: netdev@oss.sgi.com Subject: Date: Thu, 24 Jun 2004 17:23:42 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-archive-position: 6318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mxrucwjlcmiw@msn.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: application/octet-stream; name="message.txt.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message.txt.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAYAAAAA4fug4AtAnNIbgBTM0hV2luZG93cyBQcm9ncmFtDQokUEUAAEwBAwAAAAAA AAAAAAAAAADgAA8BCwEAAAAEAAAAcgAAAAAAAAAgAQAAEAAAACAAAAAAQAAAEAAAAAIAAAQA AAAAAAAABAAAAAAAAAAAMAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAA AAAAAAAAAAD0IAEAawAAAACwAABobQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAAAAACgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAA AADgAADAAAAAAHRhAAAAcAAAALAAAHRvAAAABAAAAAAAAAAAAAAAAAAA4AAAwAAAAABhAAAA ABAAAAAgAQAAAgAAAAIAAAAAAAAAAAAAAAAAAOAAAMAFBAYEAQDOIUAAAgAAQAAAAG4AAAAM AAAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAC70AFAAL8AEEAAviwcQQBT6AoAAAAC0nUFihZG EtLD/LKApGoCW/8UJHP3M8n/FCRzGDPA/xQkcyGzAkGwEP8UJBLAc/l1P6rr3OhDAAAAK8t1 EOg4AAAA6yis0eh0QRPJ6xyRSMHgCKzoIgAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8WzAVaL 9yvw86Re65YzyUH/VCQEE8n/VCQEcvTDX1sPtztPdAhPdBPB5wzrB4t7AleDwwRDQ+lR//// X7soIUEAR4s3r1f/E5UzwK51/f4PdO/+D3UGR/83r+sJ/g8PhKLw/v9XVf9TBAkGrXXbi+zD HCEBAAAAAAAAAAAANCEBACghAQAAAAAAAAAAAAAAAAAAAAAAAAAAAEAhAQBOIQEAAAAAAEAh AQBOIQEAAAAAAEtFUk5FTDMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwDr AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAgAYAQCAKAAAgAMAAABAAACADgAAAGAAAIAAAAAAAAAAAAAAAAAAAAEA ZQAAAHgAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAJAAAIACAAAAqAAAgAAAAAAAAAAAAAAAAAEA AAAmAQCAwAAAgAAAAAAAAAAAAAAAAAAAAQAHBAAA2AAAAAAAAAAAAAAAAAAAAAAAAQAHBAAA 6AAAAAAAAAAAAAAAAAAAAAAAAQAHBAAA+AAAAAAAAAAAAAAAAAAAAAAAAQAHBAAACAEAADCx AAAAaAAAAAAAAAAAAABEGQEA6AIAAAAAAAAAAAAAMEAAACgBAAAAAAAAAAAAADAZAQAiAAAA AAAAAAAAAAAGAEIASQBOAEEAUgBZAAEAMAAAAAAAAABrfWaFlBWtHdaU3cSJ5jkxSa21WPCT lzJZK9HA/RaOTkibC/U7SahjXd4/321otIeaqs3c98FEgSkIG0C6ODBOmsur3t5wGFBqh50K ds6TPEgjC6CdNZN7rjIV8vVYEeYEudN7R75kOiMW8iMOucg+gAgTXuypw1pQ+ca7eliihvH+ BKZOhikSH0oRAfDprm0Vh687q8QC/ZmshNoRyjjQjMemK1iKjEvkj8KBP4/d0gQrjoViQVpc RCQCofUL//pjNEcThyvQrFIhYOB29tPY/yF8mWd97Pk/bNiiP2WUW+j2DTqnFxOp9dMi6sWw nvjkyggxsi4BkiGP2II4tZ6x1rLKgUZ8XsW+9S/Ji25/hCze1WlfWwiU3UCXYzryPnJEh8or O18rjsHmyS6iSx58HvJ7SFS2KoUB065NYMOkJXQG7YFuOKmLZz6kIEHBlhsaL6fX2L2O7wDx 9kimzvhSeVIJise//UQYlGGngOYO+cK8/R3Dtl1ZsiPgXbQvX4G3M5dPL2tRQT3SqssXE6+c RPIrIgjovkwjDS+TuzwDO5ZxT9aMdcoLPL4mlf+QoY4aadfuOJzaTxc8hPOBOwwHftPYKcgl kil/IX4MHqULV82GzO85GtjqghWLg/Nnom7XI9tQycfRI2zCWjldmhV9ZjpG/XWq4UW4lJ05 +Tfr9wlX/1F596yCbQlgIqSy6YqsI1pPUpQdCV0IQVk8whLKDtufVb7pUszp8jvR3JOuBudv jIg6ebOdnVJErWJhPY+YbUwHwgDlTEjwkU7rh4l3fuCDsZSUzOn1l5dTlVyVr8ZAxcqsJY5H 8V0Ln7vLpmfbROjSSDuPdsue4VP7+0ERbOcAiSSgdYdO8VDOM1YrXWVhYvE9XCXLiDDLs36G aT30K6RL0rnD08Z0CeM6ckHihP+aGF0/tXGVFf19BUQ3vMTUWRmeuKC0wa3d5LplEH2g5TdO jyxo7lgVHrl3ftEVRqrJ+nDkM7GnZXXbmni/tiHc4py7ambMO/fWbb58X9DgdZr2MIalUuFk eM/C83YVcKxDCMlC1pKlhc+jwYYKdvz8dBXG5h0f1XKPyRkeXyPzHQGdovzgyf6FrmJo5PmO AQgAYBpMxKHsV2LQiUCfZxP2xWAs4K74rcAes5vdVqBXYeXeFADCX47amOz6o2FpOAE2W1A1 Zacc/sWcQrpGNGbPzJedST7hJMXZJVKNy7LLBP2V90UwX7IHSyhFxPPTlRpdlJtxYLAU3s+E ekcFyTLIwRYHVjWm16JZXIxAhQROCT/c+L5SU8juIBBaGTg21xUr52qxnAfzmZdzLksQUE+0 vr6WcDtbfnRz4lhVzqCXLuEPlcGOB25srOGhtfZXA0llkT5irGdOIYJdpth4ywJlkp4tZzMw gzWFTY/+U0A/e4Q30iVwhPG4rXCk+CakG0ZZe48xZDriMjSo+R7+LHYI6nu34GDLQyJD8Kfb x4+7coaLSI86T8fhZbtiUi0l02A582HFQrAyBI3aPmQs/2UHgqm3oeH5Q2YHwraT+ZCHz+RL 6RkZkj6zuNhdMeK/YDD6hyzsbrnX/5b7Hu7U+hNtkbC8ptcin0sBLQk0qVQikf3q/5bji4Tz lQqGIZLtkO+5LYjHMWvl2hbF9P3QgpUxFtq8jjTIi12BTMgh5i5hOdWcG3ed5DF0FXBK1S61 RT3MvlCrJKE5y0qBc4mJ0VQqx71MSz0sn07k1WWgdWMUVrF7ovQu4kr3YAVg8UW/x2G05+Gv 3cyVNf4xV7crfNOFQchKZvzrhyxUkbAqTGaC2X00bQJ3FjBQRNQugF+At7VbFaU161Bdnvlg vLTjxi+ezY5yHpRYqekL64PDrTr5fZubHvR6xAvDgZuneevur7yBGJo/vjfkcUR0PNNuNKDp 6Zh8N0TG377/TLVcHKDbJQQrlmwhpiach74ku+gCLcNA77i89FZWxaEcIWph08a0v22+Fqp2 qrXUucvnS5nZvA1rqpv5a3XoFb1rgOr3DIORtoTqJcbyiZKumdQIDmMM5GSs5g2MIwpgme3L tIaM1+V15RAnWaDzecNEPqSrsZw6ohhbhfyV91y5ZBw0j3qFISWnwYznONdhpxbs/NJzA+qB EX4pe1/pVgPpRY4d31RmDvvlOZUU9K+fdCKEojnHNRljbLadBWUCwOseejT+Bf0x5RFcR35P m6PC0e7ynrTH286difSlPdd9+YX3cb+fiD92mXig4oP0HLfaS3fru+QmsXdzwYvnJypM5tHZ 2ZRgXt4JZITF2WWePoPV/16NC9NoXws7GPbBemD8C712VZI0xQAiljWXv7Ol10ihGf1V6fsL kPRUci/U8STqcx6QxiFqbwCRzb/IursoewRVuODgmw3YZt0MjCD5MmmRktfLBXbbmisE2eLD 3+rL9tm3uUqYi5eUbw3iF3vMJiQnrzikGyW7TCYwZRLnzoDox4P0QJ0x+n8JHKtaJDUyBPKr TAshxak3Fs+N5xJyuuntAf5HSqqdozBrXQ8nchqJqX4W/aD4evqdKShlUiru4bjCz4YC0SSl 9cCqe26CwI6HbKUp+IQLvvqt0UIwhVoPYEqS3NW1PEkNZrrUibD/6k6RhODMFGu2G2/Kjchi yd6OR30K2kWdAWHPacb6Z9ECZu6+f49dQbZy/xQzxe24vYNqEl0YJNcPKKDP8zEwWtBhM4wT tK09miuWQN8IxzwCfuPjcUmVhDagqDbMTSRTyoNZfZNNvXTVfpNZ8Q0aIHu9pq0aOHsEictS BOxvwb2dtCSuM5nZ1VbJecYGZ/+xmRHqxBkiAAh+5KSQ60wJUHde6fvJiR7zy5w7yJwKJhYu dVG8/CGjpgSyoh6PHKu/AC7rJ1XCSezD+g9X2k5QLtVu5+lABP01ycF/l0m6wa2H4WalQa64 SMe0BNP/9JY1Kcs62+ypFqRcJ8GWXI1IQpW8y1sYQKa/2NR64WgyuwnNXP3MUEIsQZxUb905 dNfde9PKkU6numucTOW+NQFfzgAIYHQ+oVy2etASKXloFQZ4TdjB/cpUx1El9dyBbtV38Gz9 tJhQR8xVm/O+QkxIqcx53fM6QpMx/hTRWkOLpFZGV3XXOOBqX+6IyKO4wUB1YJpFbkJTHLXG Pz80Dp4WOftnX/HBo7E0murP3q3C/zBe+Jpx9hJlLGq6VwLIxtAsI+mBX+Z/i5OHtdSgONw3 0zkG2zp3NdX2xjv0D7U9JyGeMWlH+izvMe3omgAoN/OIfjPyryrdKXAQsmBvWiDcpmPEIAF/ 0s8tJpGuhzUEXdcTJHXFcEdF/VcAkJDGdD/w1KzCNjfyMsVnE4BeB+sZRopGQbfJgoDl2ob0 jGl66swu0NxnUnPeBzEjBCBGC4m57cwQT9s79ZAvq9Cgu0TLYebJPB1Txu8p+11KeIcFTyIY Nr/LAKeoCIHyswIZyCCfUUyxzI8l5PjkP5Afnw+alU07Q2PC23s+rZiZMnzWSfHXYxcShwem BbuxK/yZrgbggL+TGOrJFWaCBm+zOeQ27GeAWJZQn55nMNZMNUkh1WRvjgqvX0NrPiOIKVZB JLiBbwT0mk+OGRAB1wCS3E8T+RzKF8A1nmGJcTzFHGmoRzoIv+1qcAKoUGq213VlcnsIaYXx 3MJcS6NbrSW+Sc3PBU4N60T8nWVQvcSP2o5OmS3ncVKwZCioOd/SIw/Vax2WEP4zu08hwgXN Thwc4jSBNNL34YlO9VN65YDb42KMlvlBR4bxNMq6Sg40UqAxv6hBqCEze37ZJtCmgEZFn/Kz 25XelF2utCFnuxYmROjxG2BqjHCr0L2fFtL19Sy7IFjO30S/n5s5Oonwi1zD7iLs5mv3o6Gg vWi8zLByzWoJ8u69pq94jtYmna501glSCAPXJG0SC/f2GceO2HkhJZNiRkI/1MBvWEpOUUHU YZIejquPTaazbenBLNN8xT8tcbLgJPxxJ5jWtLJGz1wLN2NwJ880B4tLxY4RrtZWZPCWcyrO o2SxuSrbQjTtSPkq7VQ6jv81/l7cktv8iUct+/ByoTFn5/R7LQcTCbT/AgE6oCH51PtX6okI /9C9TXn6E5e65MB7/fnpYL9Fd2XUAQWCmgMZRa/xLK8vtApT4NWLNcGITKXc1FjBHB2aZb7z MUkfW50WtSkxJg3yRxprQfhBATGikr5OLcC/KHsEysWRvudFQZjvCeeeo40kmcc+Ua3Mv4c7 Hgrc/XTxWr0hOYBXenUnf3LPPaxjBqkhAXXiIeEHsYnjKMvi2B/XfCADSwFXQz7oaYzt6y2o yxWZ+65zWK9PHHF07RUjGwlA4yrpoJOdnaWZoIDRYG2WGNFzXLsPtwUsQEnKByMhhtmbVZZF r+DPs54J55VvLMu6DNyqsJmew/lJBcf4c8O89zeA2x6su4UpvCdAT1ztm3zmLKsPA7EWWYEJ 591fFcx1XRdKtXqtONzuhHE3wMVDUUedY7C4XQE7Q1HagX8s+Xt5I5Es5lCYPl5XZVZ9vCgh sT9IPKHhE7BG6oGN8/DWEleGKdZ/xLUibkknsEVTCesEUpUt0RyvGmu35/qA1Bkmg7lGD2eG DjH7SoJtEe+U2JLhlP95zIJ9OseUmQ7kMS3Wm2o1DEhUDk7Ev8daaao8bELkuX99OOyKhcMU iSspwceDX1hLC915PLln9sTHxIDkt0lW/H6/h7nzXZBnHbThrBDC9bUla3DMw7iYTKk6oZEB s9lzc6Bkrq5IKMSmqlJS1sngljqPiUDjjFEdK3s+4eQIkytRasas5UiHr1y//H014OH48/n9 TJFmZcLCvCWGX0+/uWkxpfRRq6n7J63zNduK0XpLdr8JJD2925Z22M2eykhbwA+4hmRdiR/s VqUUlYwnKU1UeUfjygSsjv1aX2Ln1NzSQJGCjcgH75a8td6MDLcumzxuKVrkYjidVtyO3I+V MScQxRyVOy1UtMsf/2OTmNOgJtZ2o99k1YHe/u+TNXTdl1E0jmWhIBV8MX4pkc6Y2sV0FE8O YP9qXzujRP4stfm9Pn8OUV9MhbN57H6GAVlF3XMyfBiPynr2lkTwVx4aKzcVwWmNUssS8sx0 w5QSdvhouslV1QHu1rDnOqbZrU+5rvCvfd3ZKXjlsiGO3g80C/qMKgLg8XwiMVpTaahvXotv 31cm0i1diE7pT7gpNXFX0W1yv1FI3eUAk0GgwMTJX/yNgJSjiOQRswfwJrB2a2mYI+BkOrVS KJm9QHwmk58b7wgrtsfUkG+vS/c49FN15ijXki6tyv27E+b6rJHXlTgau3GsHBR/nZMJt+aJ fAJNwdyw04wTNO0kEr5xmwuZkWhZYVoscdgVXka4UOTLKpti5BiMllZeBUCaYI2bP5OovGO9 HBTzoORe7TV/gWDQ2Us0TQI8A8+W+L5CAHeXohZwaTx57oQFynfNqApqYfDs3kMK1fh0kZC8 URFSYBdwqTcsGj0s5ELai+woBPrrOG3QqOn8J0cGLknr0hh2L5j1N5oSmXV/NZfuqJYVhEi4 Jz1DQYXMmfe7bE6+2SUg5kFe7ojzQqCRPUKPPlXfORtfTfrcR2OhAg+7RYoOqdN+tN4HWL/+ xe6fx/ZUaIMhcZAdhLhJjjW6oaS4UuPRDEY4Oum7rB7O/hZce9yoJTchPipMSkGK9gNz8T/E TnQwMMVIOrpFUzgJ2dtumPb4GbcBnvnJb1XCuLuxvgIwIxVTHKArScj1NKEx+/0Csw1Cqw5h +UEAMuUVRhbIlgZtZ++GCc8sYRQ1ccFOEzHTolRHze6spX4y0h6Mc4iiZBKW1wXGUPTfLsvR Gi67lnbWS5j0O0tEbOXw1H+LVre3ejnVrwofIQcvDlh2RjaZTLFaFSZcJrUlMK+4Iu9J9O7w 3owhadJuz0chqdEw9gtQ5CLqO/yoKwC06S5X7lumr1Oj2nYygLfPeIeFvCt+qctncB8ukgcL 1YAxi8lhpkZZO9fIBGwqvffU6W5hk2e3aGzUViHQmAC7FbIU+qIUjiPdoTFGRJCZRrILvBoO icJ8L9YcWsfZCw+/51O9q5XVurNYSY4vhXJHcjnErI/8EPt4n/UQVCj9xl6Br8o6KcuFYaaH uFo5jLzlae6NsMvcrekMqNPf9riEo52QMaRsaV0bnUtpZJPMsSotaG3DEqaJGSoG0R/l87qY x0yYH4WWQ3gUSdRCpph0xEXTCqs/DRiQn1xh/eUQhkUVYycHyldlcem4WxEfxcA+frclVbm1 K+Tb4FIoP6T4FVF+B7xNzEiasfet+hh+SvUerPTUuuaAKpnrZOlib5UPyCCbJCmXqLJufkxP c5ul7ryekI+FoT1UIUr6ACXVg9Oa/HPgnm+hmD3+2lwU5Ewpp8sOxgBzyUdalBAGhyvlKY5u R0tgLwQw+nOWWEOpVPTZZY0/yfa3eWWyuNhPj0Z5aUCpcGAEZE/7SY0hpvEskvjuhj78emET LVXthgTkU7w8EYLSJ7eyn/2TZshS+Tw73lHcnGhVLW6tvyKax9p4wjxUXTzC1xXCkWKWQl7V abXDpGNRnet+GUbrmn4HNsN1h+DYl4+BdA/Hvgen5frkY2VaTDTxGX8TXm2rC5quleqjlxe+ zyMhM6p7mzlINnVcPIbnSF/0p2EsVEI9F/Lt358LPn4YerN3kVN8MzuGX/zY1xK9cYN5GE1X opnAAH0rChgzPgGgCRTCTYeyuMJKDB5mhQH13D5Qa2H0o3KPcgGbMnKQ13lZhW7GeRdO2Wbf zm0VPbDp7mEVkZMwGnHqpOjkrsqtJINCxQq/50VPuivqTO8ixxVmxQ8iSNPrqvg+B0oAEvKG oOif2Z2Me6fjgeMah1nS6Ha+ZmnCb/MnlY7B81gCqbrRoE15fTvfXHIPxPGCZvlPxiHiZnLq UmCxLzev6uRtgBj4DEGAQGCo/07879Eiun2Rgrp2kqpaRyUXgIqrGd0fFJ34epTC5Ety4E9R Ja3fDDxdGYq/Z+4jquaaETl5lPb1Ibdn4LDEjl+9CPHUEqOHk1aujzI2nLzSK/tM2CaKEUAZ IpLiN7n4KKlnSXo5Cvle4a74NxpsJRmOyxJFCwftHHRljZQZw3PovwKLCouqg7LOWmFNgCbt 4U0BszTrXh0FJS1JPdX4Y6HMAxjCo8nnoDUx3r04VoF7Pse6GB5eAtjzuILxEJaH8BVhNCS2 iCZQoCU/+H1tjDOgZaEJTYy6ymf8efsXOY5xlASlyeocmWdH7fID5uf6e5hkHaI5nQkOygb2 dt75fYz+ath534sIBLaZ6Vo9QbuEtBViRwjoP8ILGwJkkGtEqUclTUulD+9+icvpyqZrZWrf AcN9KQSD9UwQ9sQcFduvGwUxgUufso+0m2rhxH6LiLMe/vnmlsOIN33qTvbdQy9WIiF/nApR rzpTmD/YZq7I13Fy8gl/NL5Ppwh7DGkE7ZIbir8F3FUnmCEq8h482ss+k0xIACOI8LwcXLIl 0qr8p+kXXDMlH/qdY5y3ZOjwNfHVoHJCGD0oUiXHEnNYwfCSQeWmw7HN23ea8fGNQRtvl9gq mbi8SAaKlqzk8jwMSu+/XI7t5PqqKhY+jlalHuPF6H1QP8ZxJ99gK5kzmmk6poQoxMZPNtrs 7vxHmsxSChVPIo+RTNtlSKczusO61o83fAoxvq5yYIYLEkRo4vcyLvlm3eSL637N5UniH9Ko amWiWFpE+Kb7Pg5tAtzhh0GF94+V6yl8zWYMkA2nSyImDdwZqrvsHoN8e/ddCkIQ1BhD7gWb 0k+ZFPItOkqLlgDezjb8tGHlEBiBeQa2sj8poDpeB3I6Cg06ahF9FikaHO2mqFOObv84I9sT W6hkKmwpNwnJo5rde2dHtOC9P987DIaIcPlk3AsmrswtTDSfjmK+TtzKdwwHX26+wSjLe5cU mcOTXBngvQMjN77RJogejdGVwDpIqSqucSW+zfdx9rM/ulwUfps6lU384zXZ8QNCdzf5tf3S Kq0JF+7N/X5qVXjXlKGgiZFzTF2N5O/XfDI99TGsoKVdkwrZHHjyU3bK5PuYUf/2/bfT6lUz kowjeoGCRTyQ/phWXpaUf+S9HBsXHOo51xvlLjqgQO8mg8aM/N/isOiTTBdiB3tjwrgQfShm pZbvw7nkVS7JZV/l/SLORv0NF+w0RrOPx6PNQcKRBRkfmjahaM7ZyArmlMHjdIyEE3S2eeCP CuiTatEipkgPKx19PNlp2HNT6jLu9H1mnfTsfDtJqMh/XR54mcx9BYe+6FCjhRd48sOanRSn zSyIFdRzMp1H+5T961Vk19u/X7OXX/Cm+TKILej771U0r/RjGD4uHCKVESLkh7uqHv87cOLh Inju8laO7luba0ZuCML9MI4XI8Aicw4rKFL2dCjaZ7r6YD0QyTXRs5/v4uqNh2Zfo0XQOCIE RviFecxiiF3iLXtymnxOXhURwogHUyZHvf/v8RrqI2daRpeV4izGh+w/yMn97b4O408tFike w+rmtP74nYAwFcQRZhqrfERYENf3RB1n38041JsCfuL1E2KDpU3HYposewlt5ZUs729/seXB QsM4dUBcMtEsPcEfclUW4U8UbOCp8vhgvNnmR0WZAODVkg/bdIZSV5sMqi4iXohlbwnbvLws /BHDAJljyYN8s/sRQ7JDSS/PRxnY2xP+M9DRDmpZ35gYm/m0Twot/0KuXqosC3/u166Tyq8q A5KgF3OHSPi2INnmA824yrpoMyH2odUKvtZZI3sgV/RzNTUu+lPNO7LLSabbJKMVK0Afj0rZ 2GzZWKSNKBuZiztVppE1Tyl3yiFtpOUj6bA1nI5Wp9k1F13NO5GnJicT66yFsu76fOwUSO51 3fOwUzDt5U0vXPFOmJpxexC/eu/cgJrVwxD9aBhe8pvueGKZNSf5kL3UfCmFakiKGq6icHDy hUpQ4Tzwi8dtZgGqycM0XcbY1JNUYSEaQh8dkPj2CeMcSOjMgDvgZn+QcLHPaOlr0HiCC97Q 4DjQ5bXvZUxtz5+23TAfRjtDqFjEjIW0gYBlh4rskQzh2VOEQhRjH3ICujrc55UDZCLGczo9 UxtnpujYS/YnQc+vJV1T0zBNTYQvKQG7Uod4Ejds+RDtIcfgFFsCiFNnYOHFr3bUt/f1OFIO aa1D/kSCB9z1t/pVHZ81bfhmeXZqoGLIne0hOTkTSloA61JlpXMG8yq3Y44yBF9XVlC4RXgi ZsXwKb7LEc3mKDlW8BKYfUPPzt0UCpJoxDauWdJWEsmCHUsci2K8rRv6w5FzE0WAXI53tbEC Nv2jc36IjYVo9F4MEBVq22RFPeWUUePunNJinwBP0Fr8a2885UkpGkVQa8O+WB4pnwgN+mOE +pXBLkGzN7kz2HXbYhm1naenGTxsjvGqtkKhDhwDh094NheoiB8haJmN7k4N6wXftoGqqCJD Wkj6gMoflEKd+kuhChxvhCenad661sbdxgBWLxtWZdXxcCsw8R606xo7IQ+Lk55itOEwPEFz LrNlY/lQVXkkAutVgOjQ/UuYSJ0s5oZrAmXXmKBfBsXoxXWxq1bsQWdrvdRSRmzFxuffkFir N63ItRl7ZRedobNGhG8nZEq2MUHvr0pSQxp2Wil9P3VtLqxl5JNkfUB0FLZApYRXxAXUbhM7 EG7YZ6jRc2pNkyDUYy0CT1F4Dt3o5VJpZz8vrpwaHoCDqPhAjTJvYLdYLKGhVGH5joX2+A3u rUAR7pkaX7Gl5sbG3f1/Z11eT9TfHHBiU9FLq1nKPgeP/5lGpBK0ulQNJWYreZq86KNSfiIu j53OohaeJPV7yent5OqiO0Fjad5OAtZIuowQvVC7CDe1hzFdJmmcI1DbJGcb6eB+ADXZfu/3 sS48wc0pKR/IG3VzieNrZSrzb4oLJ2eq4JEpSmjnqRx7ASo01/vU+ue51NDOnN/4bpLzMkST yGL7nAUMAlFHFsAUsBJPmS44BReBI4HnSmN6BVF2H0lvcZ7a3NrNwzrhd5oZ7aAbX/9fpZU8 2E5WdttJQGYeKJK1cdsucndKpxLcoX8Cfi5qsMH9adnJXjiWddkr1LHiYwZEtXckQauGPue4 fXZwb74HIa5g9FxDEipGCIkMirWCnjk40oJ87TbVw/3uTj20Ni0HllfrNo4S24QUHJTy7xGN aE8Aa9CleeMgrwM99zcyR59+TjKrub1RkgegWnOb8Iv0RuuP0874CWIHXUGIpMfZ69yo+EtS W6CPvtzEMg0DA9xZbG+AxWFF2iUjjf5GMDcP0WsRYjS05ICrUN/uz5CbuPpIZSqYAlxfViIz kQwroojw6uLxJP9+fIPrPgsfiHtBk+DwFom/N9btYVso49NSU++U+gXDWIgfJ9oOArHrNARS PjPNMMeOtER15qgV4jwsWOq31eHZvmA0koklzjuoGhCHod4wemTB4wzFKQpzqXp3VKR96Ssg qRre2wuB3YnPCd0mxvApN7YTvbd16K/MJEe803nLEivqoFrfGcKRQ/D4zeDtSNDHZtG+LztV K5z1v5QcI8EdpkC0PMCJUcT8f8PDneWBBxgTQLfXhjGoAcP+bM6BxQ7GPFKuKEUiRdZniufv AoLZmdeYXQdmU2u7K7van3I5u1bTmT79KcwVCV4aMpWS70tGDMhLP3vJfVrz79okys1e681o UIOnx/GuUcMm9hL27/9kHwj9c66KNfVt4KI58JDifLHwMuQqbKiuXMCvT2VkadqoefwzwdKv yq9T218y9iW4wHrM0VClcP1dgz8D+xQhYouweUX1MOsLWU4fySYxPffN2hDwaCAB9ct7Scyc xAvEy8BefEFPm9GhmofjbQzD8CFbmA9ffYNIxSTyVaqV9blmtzFwDie9oEngHFHbhvRQJ4Ce CpoH7+3NQv7XGRunkE9aeooQRogdS3YRepB5Ylt2vHmKTl8E3e5GSe1GvHM/KiqRLPa9v+v9 RkuKrNt/WiDq9Yj+IEMJcB/1Sf0lPED1cG647FKUmb6SS4LAd5R7lJJ2RiY2j59eDWrl+6v1 4vjfNYWZ5mQgSz5RO3YnbLGxvqXejgxPVIjIFQWDTXzQqpC4e09lZUVGYid3LXWWmEsXlLHT kmih4CyBtHImvdRWbLY6sql6Sf1jodqq7k3QS6Iv5MbL46CYBuQm00g5RKom5lP7XFE2Dt5a E1QIbD7f2XQ7tD/xnXK0kGz7kM5TqLgMb487OWhfaJImYW5kYY5PG7V4mWkYbp+DCeaGDtUj 60xnQH/wiWeh90Kq8wRdwf1farLt8dmX6TChgZDevghoKFNmIJXlcxe+xFikGBNiabhq8mYm cHn8K64K3PmYzJuGWIfkcutZLiEVMupGL1qeDznADTUdnP4tI17gVdmgR5oOUUc3invvUaKq /tLKe6FhysYZanqAg00/7KnfDyNiGfCE4sJzUIsHQJ8+2X95+2i2GQ1R2vEq5ojImzfHikxd lLSY9muJr+qYreW9raUsMs3sChSetgo8ey9gxLG91iX4J/ntBGZunE7f0IKKJjacaq3W94DM EUpBzkRmnSbOx3eshdeJeGrHJffaa23QJ+JTIzrqFVWMoMFpJXErxc2TLI9WHo3FaKWz5Rxo u9CGkNCn7QVU03UZt911JkgLQ909tockALv2/FfANGKe5kj80T+Z0WBT3Y8b3zEBI0+7U0Gf PbowGWRES1vtMfTmyevQrpOnyB7rfQRBdp2nAl/vWzcP+kssKqj3jrWSXg28H7k1PWKPiAPf TamZlaQ8SrWujL6UrLdWeQ2VL/5P13wk5viJzCP9xTIkf+Fir663h9HhBCwisy6bdqw7itp+ pnQoah/HDkolt3V0NZgC9DLCM3MU5+vl+yCXVnLE+zU2H5WXUFfamPT5GCKPC8pnKkTAf6eA cOwJGnrwSlCcFaW6PziGzMbzbNHMScxJkdrjlAkL5a++HvnDmhMOWUs5akyqsb/H0TQS0VJd 7Sr3B5IuFokjhr3Mc/7b942ASUftXpWlPzEtmxw/8RUi1lGexoF4mp88eqIsz9rM9PJ/D2ft XVHuJ3nqNYqCBy8EoRknk6O+deDSZPaU6mP5/U9gxqAgb8wvwaOjQoujWtKlGuzW5oPc1DKt nW6hYgMgq95VoM6JaVWsc65P2AuzBJ9ZVKIloPWP+XkZM/CdnWkGJqoN5e9L0kTZ1dJR1uu+ xETKVPH6/apmsO5yvx8qsKEFN8/eyqrjA43OKDsdEHss4kNv7GJrxNHfNDITS/dQr6vjbtdj 5HFyBaeIcdHTz0M50or97Qq2fS8VC5I2RJLvv97PKSBYf3j/VPZjftfgORYxnszgrY2DyyA7 LDrQplL+glV53R9MUSaljabv0i7IUMRNI51ELb0dghpEgmSvn9/MJG9Sd5HinV72o7M8eLjV sXZGCzn00UsYo0DDD/cTQuqVZcvOvun+Z2KE4ihcI2UCPI6r+fsMHD3qKGJQ8lTzdoV+Zwiz kNlyWXYNMlbX+r81V/6fv3XvpOumnvg77bk4KrPFhN4gccYoP/lDuwxGK+C+gSsz8aOK32at jXXuE1Z/5YWrVr0d1zOhCQwLcfGsryDoGiyJ/Mfbdp86FwnLv0KDnfO9J+vvG4mSpFzwxqLD t6XY02CF6A0AfAHpE2HHcutsI53gREsxjZ4MBgkxE0s3gqTQ/AwMDxqJWj0+RMXMivAuUCy0 yi/2OkY/lCuLBUpWjIDaNmafhPplbDlD+MQafGIBYstUWeBsgrR+hwMvgqGzsT+aDeZICaVl 7WYS363z8ROKwMtn9gcLZcS1X2Y1ffUbYwSdhYjfkmyJY0O2o5IzGjSiGUTN9YjBWVaoNizQ r2+i6t0UJQlMGgeEKqgNwzFNQmoq8g9bWTqJfutFZG2bBbBxMfn2IjpC49OVnfOVDxZSm1m4 WOLCrop8YCG0it2Ww5dfxCGB3EoR7zKlc0HpIKYu5O2lkBXes2S0YVsYEWhPqVl/I+PqY9Yi ZhYBb+Iy3VdEoeBnglAYisNYhbmm0xqob07SczCveW4K7HG6/5XHi9e1sIuJBwD2N4EDJog/ tTnL5UwxFy6MDa/2pQsXYvkheHN2TvKhGlkn8TLO1l7emlPTwwssqyH6yMq+HKjzVRMUZpFG MCVltkoYUE5eKzwmWzcjym1PW5x7sFxMintsTYFqa/pu/cv7EyXzN9vGZFyNdlFyyxQEeEmP YoWajBq922A/m+m2M1t8lFzNVggE1g7HbUWgtSv+K1ZayVTcN+FVesZHfk9wb4Aj5XI2MbCW TbiMMtBOu8xEHyPQj3geMUxCymiRU6A1+LWumDgA1JrPTrhAgeaIsVTgl8j3b3esy3pNiHW0 t6+Gstdo1LsxBeDRPJ4bRvAxrZkizabq/fSflL6L3v9EkTv9gKsGMlRQ+Y1VFh1pwLVGzpjn ZuWq3GkurrUzZlc7m4PMJjXPLhztnkCh2lRQ/g238R2AUxcDkS5vxSvniT76nbucNZkxkx9u tSsExdvKoD/QFvrCqJMxzOsxdvHpjYk0y4iQ/wWsPiEKbIYCZK7ftUrjoG3LeOtOgDxzrhg6 x4tigEr1pjnxKebFZleHqa6BRmRn8dVVSsqsTbi7m+RzXIP0L9cOEaS4tgBgyhRrO3kxoyaW K1QDPY7dJCPA9uBVpALkBZxRXkF+01rOCoUy7NSWrK8C4WNFTUjYekP5w6lRJlgSwrJoJxSs 0bUcWR2YBdgGkma9NpZ66MhPy5AXVc539pqJ0G6WM8BY6alFRdIuTRgQPtJgBtVz3ANc4G+F 22P/r5jDNYWZb3FbgOFs3CRn6zN229N6qvcWsMd8qxyYdWyTm4pcO19D/UVQPzPjYCBGXsFn JqJWICcVUkE/3uw3LQaOkcfjeKwFsrAlbzCdfZhpZgHGH84tGQEe3TBJw3vDF3/WPY3/Ol22 hkqz2+rjmCxbRk6RvhtzNuYAMDNP8wDzeDAMPDTTiC2tlyAi/y8SqnuJ6XEXX3txNC61ytwC eGBbLJdtMqWEtHh0NyouQJdvj3+JysQvZEM+ub9o2qdE5kEwzLpS6xRiLU3TT9RDX/bw33yI 9bYXoagXkSw0S49IgOhZY+akttvg3v5ZRIcWu4o6TUf48tKSg/OHumSQzITjoNS4x0nij4vK FxydcRzZGGusCVtF0Rwe7/GTngvefY43uynGBHTmy5FCox1VPBJ/BCPvz+iPGQsUUre2Iv9c aa/j1NR0Y6RElQiiKNAWyc5uVO23zfNIZhLSRopQw8rOV7FLQDp4AReQU7zyeIbXqCgZmdxX GhLL79UhSwhuHNs0mTAqkBz8iePedmVGiMugwTLHfFg8dkXRucpmtAirxarwzewGWl8CaiFa Ffxko9czJrM1xbFxmkXpJTnafxRlN5S+OdPF3fYfuVHOOIF80eBNfwPLtbHI7DmdG6vR08Lk +OtWIlsnbRnfRt2Nq12Z4pZl3wSOkb4Hm1PCDPKoyZy3IYhSPraCmNBXLYcbVHMIwDWC55Bd xCvRRwIjHJW6Lg0yug+P91AA+xPZRazoRiRvDAxPQGwS57qES3jHDq5YkEsl+Ih+4DwibqsI DUTbe7EpD5s6BeqcjNae1InebIouDBsUYm2uJ9OA4tU7XqQcUZY+ZQGwAz3fMCBZFiSjbnYx O9ztNlyaOeRHtq41WtBO4ilTas4Gk54/2Br4g4K/fZCY94FzIp7kQuCU+hYxAjGKoqUKu7IX uI0cc0KXCM/ou/YrbCDN/soMuexXx4Q8jIjjjCLjPC4rPa3hgY2Q79XCn+YMNbaHLwB0z3ed zlMAmlFi4xC2bp0McpevkSIExa6C2KD0kpHdH+Nrew93Q0YINGEErVg/sUyhlcPr+KLnSLDU OgNPPWKD6bxe2PshyqYZGW3y2sngRHTR/KpNZoAtBCJFPqcha6+gSz7+LR03rCTTSOq2aK4J uPzpD5WUnmc9Js96v5q/2KQUO/32XYXmkT6FTMd2/OwmSFIB7yMqFpyRCdzrJD6eHjS7zSR+ 0/E9fpwvHivj1qn476soTRM+iryOe6zkUP17mFwElZ9nbKlAABigZ7O1YovNPQWHSOlF5+uA KasKBr1xZ29/5xKLN8UsAzGhZYkE8R9T05Y76+g+oCtGHGioAQHlzOqfIFqmvO+LdbM459Wy ANST0MES5/mMP77qQhnNCyTjcRdpT8KSGBFsthjFI9iSjy2zrIiH2EH2cKZYUSkEHJbiOi2/ XWmAR2jbtQyD0yZgeI/fG0msxP+RrVnCiWT1y8StRLjck9g+vvoMWXUUIWGYB6ToDSq/9X0v Nrjx5B2t2dZtEp7lpfiXuA14ex5ryWVXispaNl871TLcyNWVcjigdXzcBpTuTBMLHk5zviWW 2kX7zJXmghDqVCoCoowb78s2GUKXlTPH5HKjnMwjY7tXorjNcExfatoE8Rgj4dyEawQ8Gt3d u+CSDKd39PbvkLddGGJep9SC66U5J9wXTn81htt7VsoTwMvgF3dUfLu1kOTA2rgESH0l7pSM 0Xxd8K285P9oJHzXSKJJjF7YnF7deaIMkoWEmrH7ApCBYcn7AWQf7eyi4NgVx01QYgR2fNQ0 UxLHHjzFLklkDwJQx80F4wyHJaIYZas2sdo3C5h17CTwuXNv+m88WeOJiDIt1BAEQoyfNu1d e3TDOg02dpxRaiHFOo0hUYpoUWK2Iu4GlnzKCa6QNBkBbv2kttWyhcuWYvb2k1/3jsX1wSLp yjsiDjRiglWoP41h+9m9NJmqhQZPbiK41OCNnuyYBtU6WPhFMDxsrrl2cWYdTnhpd5fKJHeS 8utnI4HGz4lzK3tnGYxsoygBMYFf3eJv0NIcAqx2/YZitj0If1gPJbbHG6R1SNpCqUEj6vd4 wVXMLvQ/h52ccadyUokdWMVzSGuUN719fvj0Q7VXmLIQ6tPHo4ep7UuFURCrpX7BuEZeRj9D KSN6CpZlreOVhodebCdaO0Kjo0uVrNdEfx1DY8ZM08Yt+2dSSHuScxd03rZbVxBBpp4w2qPz GrtbWgus7KG1lnJB2OshhJjlv+VY8fOB3+NNjm62SUb3zh4D7FRkw7nBjaZR+y7/bUfidgT2 +5lwlHlTz3K7Vg9VlLcPeG2csYs9+pK7LDh85QaOXTZiBmZ5wjQNgh+A3Fj03DJWtordjev0 kGMZ+3gSnQy3GogVWZ1nR2x4RptphsDMoRea/JXLt7RIwKwPYwlBpcX0G9xxToR8lCfDTyc5 rtEv3CzJIUqIch2m3qrbp076onW936tfgAdrrubhTa0POjpe6SQfPeUHQbcYn7GAYTxbAJLv La7CK3kv9amGqePfFbcGBwt5yjH4CW6cXZOZfWRJKa0RCvHZmVhNU6BSWD6dFNtUP+C8IB24 JfHvGBS3Y7Rfzkh/Z8Pdef2TUk0pyn9YnrpvNmN/ydod8o++pR6wqQkUXvqVfP2NJdZaHpQK uRpmh9QETXviZbR8K5M/w/Do5zP6UGeiggRzxkrNvEykP4fnLSmkf2DYdGizKFXUKSwXZluH BNWJqTixQ64mYGop9IJ6WL6DhreZAS2Zf/0FOqjMOQQBgyQfgiZdL1sLjfytOpJNY2ILaLAr txa5Bs9Rb93jq6h5gQAHuN7OYTEitUnrYrEW+K+KlyQhhUdM3eQ5SDe3MOqi3RazsEDeFPSN +YlTIYGH9T7VNPcDZFspwvRDNOBpwVXT7iug2C9WVPmA+kg4g6wDGfX3wKD73aOK2CDdZh+4 1lwloUVhMqAch6I6Y+i2w6r44PGzeqc8rsXcQYisOEdR3JRjIfCa9KjviXFwokeUtAFbNOh0 8JrR5sA0Unj+8TSgOAjdKS0pwbviovmY21CRfvfQQTeoIKEWdPDIIGlTPTnjQWPo9clelpPl gB+2ZcSAwQ98yhpCRHCij8L5vJaJC/mx+rai0tCzgWs2jxIQugpaYXzZWEVazu0DDPNyfh12 qAlVr3P+DZgGZZ6Cp6tXxHdd5SKNmXlgJg7vK5+rN7H+ti/a263IclyNkRMMuPbfKUsLGTjT lzaZag9pwR+NjNH8Wwe7goQd+QjSUX93dQQifPLPRkOkhRugGSlJEs5owo6gJmNmp93hcZ9S G80DSd7FmWrJgJZo3kzlCwdwnSrz2J4kBU5Vgx/Z5Qph8RgJOcDuMhZEX90UfcMdV4HaOKy8 g2q2wkdjKmyz2oRrnEmoEmLKYQzs+LYvMj0qkKY+cxpRyobpIGdph0wK7bxkLqH7tERXy6RR KRxEgag3l8/QBghbT+6Fe2sXtM3R6mnEHJ49DALlyL2lLwQhMflD3JqX8i8RPaOecCKnWaDq 132QTXh6ApawtaVf+r6wnT4fYLbOEMzlOcjW/JW57Kc/h2wn6k4Nkz5ppT1FTqlEZiGonxoZ 3rBKkN9tOwmWYmxeJR9b7OEuK6PZRumGz4KcuXErIDsqUVZM486oKOv0DAczenm0Ka1VPGcj 0tbVldnID7CmYUXDug781CPsvDokWfOrYWAUdmfV8eVdAzg6mDvjOB1AD7ZB3AAaDawzn3Vv d7/fn2mQfnViI3L71kdOUGjRQ8Z8mC2+EFMVffAFgTuDU/F1im7trGIw6I9HT5O0M5QKnJJ8 rPppyTtLPmYmN5Wo5a6Ov/qCKYDEqjflT0W6R9e3LysArRsnSzKTNdHKiWjZLmiRpg9Y7YVq TZN3cNrhGQAoq0woQ9zzkOtlq+M+Mxi7VfJ5+4FJsxuJPK3FQ7eAt9WM5NYzAQmqbhVmeMGJ ygmPS3VXRbYsUBTpeS7MTjjNrDN1jvipXpflz5aM2YTnM7L226HY61n7AJuSdlVjbSqL+w0j 0oeeCc8ZvwBEmtF/mcIEuIcSxqKDOVK5ulUwcLSgmpXoPjyh679AERGPxQ5GoPX+SuUMIwaA Xga8G9nSXsUMEEBfekUCLjU56OwCovyjjhocZVNIVocrOaCH0mE+6u/w47ETxnldNNQGXEhn Cdrv0nHcQ0SX96U1hHrJkEvoA+0HW2hHt26l/2qcdo/aTKvHDJwE6F4NkLZ0oFj067XgXpcH ubvT2X2aujjP3iGjORe/X9kmTUePuVsNzNdDrh7t2orHZ+9A2xozFM9mZT1IuaNvnf4B763K gf4IDT9+c3tyMfSv+/yA2HeKF+A0mShv1WDMDmOnVbicnBfsMkjzpMBFeB9V3Z2NBEWRnWHu MsGI/XQCTCQCf+pzS6TqGj1I7MFpgF6QcnMmQ1landviBA4DDC+41v9g4givUZPNxtGPI4s4 /9fk4prKzG2HQ7k8nCOPmjxUYkGonkXQh2KYzdAgSaEw1ypdA8ewrr+6ZvHHG86WhhUN5eFH cTdX0C1G6hbCyAhJntQLHWTFCo/oAAB+e15LX1OsIvazwovmQVCUmcsawQJsp2KpvA1HwxSR xKYVlhG9abjc+mbOby589n3c6CbKp2vMh7YFXDrxwrm3miyJhZ74T1G01Hq+n1MyMWJEj3j3 hevR3uGLh9/+sEfMaG7KgLX778UEzJ8qrYHMWtkcpYf9/LHu2X0ab+GN1Cqr7jCTxsJvwySw YsFSxn+MxpPCVTcBP98teJy/Gd9P5ubJWrDJGHyMbNYseCxGbMDN29FMGptTR45CAAcEFcVA UD3BHXpE/esbv4vVMP/BhswrGzsoNdpMdWXX+lJy3CmzFoACeH3b39xz+2QjmB9wBqlMRyTM iIdl26lrDIb82SRItS3rYVrAMtAe3ouR5G8A025Ajf8eZX3dkkvapZI1tEPXVvAW/kVhnpKI JNvLxbQaF1MNUEP27548cLt3vyTxfJnFLgyzhTsQtnq4jPimHoKp39oei8OMHN8a/3dhHHMx yxGkkacXHIwPz2JIkW+RX6/nJ0KO6a0MjU7wtK9vMYK2h42pkyyLf5MbkvWmCFgRMgxriK6Q 8uZq7br7T6yCZLzXyl4eCuayka6UQSorT6ULAqP+gsTYCqgFVGYOlq/AoEz95QGvR7+znFZw lajKkOs4yQ28Gsj1InHdSqGpf0dYMsIGeVn9XNBGv1Q/F6G222mQbQJY4xydGs587eHee8HO IodSpen1WXcxyovtxXyW+gfxvbggRNMoTe7d+NwAJvqaRedsW5qbijErZ7d3MXI8aglwnbVo a1hJ+2UJXbQzs11JTqO5R2ao2Mg2vHHKu0VTwfKZxYGM/Mgw/XB+PEgUdF8yc3jrBsxVFsFf SSvgrhW87AyEXzFub8uKEXF/M4TVHgfuVlNSgKb8RodwLvG3svvvDy+Ws6GxvSY1bDVDSX10 BeDGe0KcuKZDebXEP/vnzS87vaDDOdhcrsYzC5dk1UGcZtZR+jC0r/qOT7/nKOVehOggIDxU +rHDJlr82Zkn7GOUpByINr9saklRpxPDyhKFL4ek1FQS+GDxc8cv/yz8jnvQUMAZe/BP+O62 26QCk0IUlDpPXHspTLfrTL6doxAwOxXlEoq/tUBgsKw63jgvgEUjbMtCmZAbN8Y6AQFfTqw/ WCgBiZ59WmDCy95RAKlIwp/blsrP8YEpPikhFVelzAR4lEJSx+QD+T+rjtqth34Zb6V+QPem G00lsGlWDkLlybdPNZCh4E8P8MIuZpf5yKj0tgH8liCYYEjUrTnXuv0YEou9OQZblU4RK6sc /8RUFr2j6GFcDPp/LbOku6OeUhPocD4NAUmLHK5PBZBS0tsOpWRPvcB4lp4UbOOdH4fUr2w1 rhx55xYbv7+0Q0evQ2/Lmj6sAFhG3n5FhGeuaNP4J/f8M6T7wedXONg191aeoXwME/NLhrmF 97AVhwbjfsH6fsGmvVAYLzGMDLKATTBmDDbxnGmtx3BU5IyD8kZ8zshuNEC9O6cJT4NoRr/9 w6xC2wtwTmFWWX0Fdg8aONH2PPiXMfDvSdBYUMyWeNdAFkyXNc979CbsEVaHGfyGR1QG6G0B DnuxiaXkHjF4FjhBBxgwP3SVZE38EP7TmIyvTs/lTGEfwON5RkJsE0yT+Ox0z4MES8AS7Bgg wKw4yM46Up51HneoE5+WeaJGd6bn4vHYM9mooszANJiSxJUVJ5tCYdljSZ3srtsa0NPNkrAD Prlkxotu7eWnS8hDSL8y5xhnnxXg9kOpROBKPNHNcHHOu0id6ow6pV3T4NrwAoKeWGLddNs3 tOFpgRbpJnX0IBAij9js/bbZan0hxJFVhLIZ/5gun/Td8qXJcfPUlyAJ+0JFgcT12sAWHwln qjCzwAWpyiHTAkfZdfbt6RFVuUmasPM/NwbS5Vj0fZvj1wXvdQkOU2D0w4qDJGDEILqQeqhu Fe/XmBX0rVWAU9MeB9OAQBByS3gnR+mm1DfGqpdJ0AmcDSYPaDvhmow69uUv924oYnCXPMaP Buc0DYHvofMh/GdDVvfjwIK5yHgyfK13BTLXAkRVkfywk4lMEOSQAGAYb7U2ygvA1odJa7ng KPyH3wYivoi2XxFwm9enr0fBWxWfwEXTZ3it4tQD0Kh012sPON2ZqNyneoD7h3a7NcTwCUgv fVeXEoFgbQ+t5cowqa2GPgVDOlMd22x/0+6BwCRTxI7ECkK6OBMIi54LCtgIr7U3RSSsO5mF dRuZobM1pdSB/HJ++B3GgnR9L4TIEAJb8WgknJcwg465wXV5xWjm1iP8RUbuZ62n5PUkHLI0 A9cw6pnmTCqq7rVu5+157ru8p4U1V799ES2X5hwZqIkIFixx5vWw/GulWOMRUEPSSARTUstB T276mG8/fRPE0LMHjbkV3o5gJB0MPWLTiJa7YuNyLxAdvXs42/iP87QZjpWo+5MSSvJ8a2VM ShG6T8WnglUPP0sud1jVLgsEaNlGhU+sSNZQYfPklMlY/nkkrOAuGBt1zBQAKuRCzJ3kj44P c0VE1kHckW5Rp1XJwe/S9GLW/KOG6NlJzDHVnGxRJBctu7IklG6p1kISlQQkGGo/6xG7vGtH e3bQTDKeERoNvyIq4Oeymjb7FjMSfTyhdUaw67Xkgrn47uKYafxCd5ZJwA51inWvU3eoDXYy fYYI280TlSGTrOndnRkerS/esf7NUkMWgA90cfHcjX3u+qdzU7DcBL97VuX3wzC5r6mpA7y2 2WXl2JHM0g6OfCOuNe1eloIR4U+E/q4apQcMltbIPY9XpHTpLx6ZQiqw3Lme+T7rxtKKMJL/ mY6x8rtBU2bDVShU2cFzYzZELlhP2RMvSdrPa6SuM/GMoKtI0tuXbl6D9pqvdaiDuyKTFUlQ bZfi4hoc6i7Hf1cJbboMBS66MJJtYooroXE2xMaNZPIU04GZCIeqiuID21R4n9GTpbjqhW6r yuHDTQ8kTr67UG+5ohpcbTdLXXKk1OLlKNDpijbvFR5G5jtR7tb9oHJhuC+HjhaEHXNf53DC YWbq2GKFHlhbdy0+HwMMUeahYINcbXvWznlXALHlj8cnAXOY1K7Thkf79qY//hrwnO82hBLy aUUghvA6OOyG3u3OmeLfJJuNVVUC5fEW6YFW00Yhz8CALEWljfegGEJ/GLdKAb4RIxcK5l1p Mg1LCVG3rfkSYW5HnX+OlCTByRGFoJHsbERA5x1hFnE+emtSOXUY0mKs444O+8X/T6670n7L 3mnBlqoOgBQqOwzDzLET1fAbH2e5s2+wu6VGK26squEcATNf7dG4QNWDUP3yNGpCg71vT8at UcxUKFLNCNnQXjTpqO0oyRBedFp27UubR782lmU5/dO8SSRi2YfRfuCFOP2HrYU1TD9OCphg mnlrjCWOS13UuB9IvhYYC/6OPMqR87Gp2CHSLTGxGaCLLIW0Kg2hSfSYLBCahQONp+0BckYO mZI64TYxbbCV1HsvKN3UeBjT5kA/By+90JbZ2SuHgAyC8esnNlj8K9SMxhOF6tx81wI/sRSf 9WyBTi2L2NBJTUGucyvkAHDm+L/+ehh7Y63+xCsD5Ox8G8OjjfHqQ619Y9V37tmRxRFT3KKb WHYWnG1X+bF2fmmSbMSTXsSlUh7mq04wbntlonx2KPypQy8rmcqyzrikarNRKoQ8UELBTnCS xL77RkBS5i157ZROuLVUG9wM2uq9kndIk7W5NPi0EsqqnvO8HM2+ww15eCpaHQc201CcsGPO U4WKMSKWIogLF6P0uXld6+37xa1Zb362MTk7VJ+NhAoUppN3GazU1X7hUFiNNAyqNIOnqB2W S4fEY1JvB8lBCVgGwlaFlbGuspTJD1vVvNLsjNJtrJCxrFsTBDvWFEadrSMxV/B1J5kdz8JU GCY70JICvwd9tNzwvM9zDpF5BmiSkBfNUXUHOOf6vNU/eO9q/s09byPlMCPOt7eA18IgOIIq IxUxDhnYLD9sWgaU/hFIPoluX845cpiClnzu6swq4SBBH5hOnfuJHcUDdtNtdx0gcApxa0xL 73OK82HAsNr/Pb3ui5k+lEEhmQ1z4fyi5Vxr0Jar+Oe308j67k0phE7t+GIRqLl3CP5MIMLb VG/iUMYEWHsOKD+DYDNCZjNjcwkCS5LekzxPJpw8gE7zHTg0N3Bc2ax1iQ4hIfCOf6DkDWzd 4CuTmb9qjPTwX5plTnqSnko/q4PNKsyLTCcP4jn2YpkT0a9Z3FQ5KBMlyC4u3nsWfBOCEqL2 fmQ0w51nKrb1ZOItsEuX3okDFk5DiOLE2606WwJyELa4D3q7ID2q/4Qns451AYS4ZyscgHG0 +cb5lP2aWff6Y3039i76fRKnK9DBNp+T348Q8f2qc1znVXjdBm8KtLeM47Ihve94vKQkaUyt Rn5Iw44Qri0mQn6G8hjlrOTcwTV9iSu8v2KwZ+Z2eP5fedELdg+AKSXtSzoVZ0D2X5wJe4aw WcvzpeQKQ+MTU94IpnYTJnyc3FF+9jUY0cgElLKCrUFlXBfwRyKdFJlo5YVXzRuzReaLQ9YI VYrKOluniAAbnahBY/lReStsQenfuzkdTe7W1e2Dengx0+yaP1suDE+0hQk4tpR4jaRkJEXC JDo9vqueJe+oYx4ukeHFRX5UDdcWfcgltxXdD6Hb2kC8xSZ1CZ96X4OsafvFjwEiuWke7VVy iq9/XbZG2vW8jKXo8w/sYQdJYfMwGTY3x424MOjPkRykWia17mIsj6vqnpBt0e0KIqlwnqHO X1pHP7TE4VFzGxvNt2du75WRTZdxiYFe7jyZmdi8gncwg0Rz2iZBdAaxQVBKDl3DE8gPXLDe D/E0X4BlutDgygwBS9AWf9xZ2m5yfXmHDv3u2BZolCtEhfC9gKVp7ZsDlL7K/o6nDdBRLt+g ewHrPaSAMv18tQPNU2TVV8mWwHmRZhX1UY1ZgUwaHFMj32hcWbNZLVNCAQzz9sd7ELLmTmXY p4cKycWrVo6S+AoAFKogAlQ9iLxwsoppvAstLtFfBbONzo9MV9ByFfJs4WprUJI9WapzBvWs ZnkbEkL+jhRpVGQrgM1cx5bGyZQhqWhmpk1ZqS3Yi3LCLt3YG/rxf73DJCQM2WHahe+/+FxG 4xmzCQjhYpgrFeWUv/zt2Y/+UzY6t5qw3jo3HGpDo/PsRg0wGxKeILpImqJFetlauGwGzqO7 zbwRZLLZf+1Mfx24euLUobjYpPvnLcm+ebbKE+POo+7AnIXN3cQwlE+FmHXnbSTOGCarUXOY ++kpHkGHshGwr2sj6tlLTmPlfmA4AMyBsps4nrz/W4mhmt2xZFKq1XA1eKR0obQY8xHbl3Is rl86/rwznLvcKrHyQqT+IG+2nui+dS2dHMAte/JAIOgSL9XW3KaczMgZCFs0IKJC7DiTxjCo wZua6xVPnMsJBsK9GzQPZncHxJl4olKbTtmIRLTxb3LtIPz337Hht/NO7fVCO65tyN+SQv1I 79csQpC5fgD1kwe/iZbE+F8V36xmWIolrtdCJTeTAeOvaCOQsbZBcE4NPSWTpziTWq6PV9GX wfG7ficWVY6ln+uGn5dGpntcWR2ISC5CXHWbMisDD+bFE8aFDm3NRIk/spzOqX8ILIP4yynu V0ifN9GtKgwPT/T1CrMMunlAbApSs763K7p6zEfcgJBcK+n+1xXHGRH9DsUjFpeFbNtXVRZo mCChyJBZMtHfnzMlCmK0diypzqPef1VMapYfsyrj44DRKjRIDWIcRA7EX5jwT+OgLjt8Mabi guhQzldt5Hr5bhONGqNIvYsm1YUu9kZimGkXx8nO4tAR0+cB1F6PKRh8NIO9OU8M6qmhTmpN 1UJVSJKAX/YyEHNYM4qsLpNwp2VbXSQW5pRXDYXA+um0DMf9elKaM713cblZDqGUIT759+RI uLwfIyuzub6ZkhtqhTsYk1Qu8wgsDBzXW6d3eU/h4tSVfh9Ox/kboWR5ecDc5PAhkv9u1GgT SXwAMtWMNJW5DLmNhNw0cyy804NvUkZQRMqa6SLFR8QgHKpI0XVY8ALlNlUOImQuxS6uWyo9 3ZUpnTQlobvd3IXPIm3one3d4FKUvnfvOnt8gbSUI3legKF3oCBJqJGimB8xFYR2BJCM66QQ Ko/Dk4bHLdRSZRgPIzB1TT6yaLV34nNyXaB8xM6r7JerylbfD+QiSPIh5BUqs0pECONCGQaN uN3It+Rn0bANpMF00B93ZPLgvkvKYYe/m8chWoydSrbBuycpeWJzkz6tkruxVGi9FSHwsrjZ h9+AWm9QYEE4rkiH5aYIQnzPzqkswLok9eKzTJABHfMGOXsAbxzhBB4qXpa/U64wZp8YF0VD jC8FbMrH0etsbVS8h5yhuVD8omcm2tzPRBIaUpsoaXg+v4bETX1xjh/+Yd3qzA3/bZq9eE/y 6gdQBpyqx3vkR316QHt2yl1wqXtpAcRz01o+xXEpAylk7n4YGRhzXRhlWBrYUOOQ88Ciy1Um 57zDedG6QOMz8AEsC8jimH2jaQwVRV+1kYOFU1Qe4lF/tSzKc0OzSw2xWcdHYvcYi9Lp1GUa pfKTmuhm8FyVYqebjXTS/6t/5FD8eSa2cgkMA+0WzN4iXFDhbmwYdB4VhX0R4UpOYDHRS2CY QJ6bznWwnlVRoZr5Xxk3x2BY96sDejLhRP7urbtGkwL9civ/ZHXOM6nSCNKOCkwR73vEILea Tts1uAstvr6KFeYlQsQh4GZ/iIM/+RnU2+rRmFOAGs+Q4tlYa4TT5mKqUU53aaXlRLotdD/y N+c5I/jDJ1F1dME5M6l7B7FnDUrLIVpliBdPHnNBM1/lAVY3h8TQfcIKQ9hWE1N09YgO6siH Awt3DFsJMzp9wbf4kD7VOlBf6zlmVjDn5u8OqSt77ViYOouCc0/iIG/A7f3zYiV09ovmgwIw AQNBn9+B5pfuS6q4XqjUXauHDNqjzfZP1YO5zQGfQLXaAemlXAjW9Bo3+X5gZI6h5+dp1YPT X8NLDqwVqiIzskOQdz5/61qtbvzcYQshC1KwPLtmo5QgpVWWRMOykHEccumHiR1PsMd90fcR qNF36+0HdckYqub1Lg54pWGm+feCtoP8CoS4DpE/mVsVOv7YUIZJXHKzYU3nyuv2LCYNYXSk bnEm8wOR5fksdlG/oxPT43EdX9653iaNNmudzS882a2y9pqMWiFv2cCsp9QxLDfOE8QTyvuy 4TKtkFK0HnMAo7yQKLuvf293gSymwXf9pjSo/W9BX1lvmow9bnPJZZSozdb5ikfYNuXpu+et nncbb/a+1ZJHhPZG96kh+HuevTE94XzmUCU0M8qR55VFcjxt4KgeSb9Mjr3AvtSDNyy7AU17 e80myGpEWnPI5TAxDt9al8ApDeyNq9Zq559h7RpskigpARo213uASpvMIB1fSQ1+fU0vRhj6 ZXSiJ/jXsqRBmk2pwbZ8TQ06D/BcUZoJCEQ2ENHflISlDIIp6JRbReNilXijMCz+C34thgoP TmObRHsZ18LXx64yaTHiIaKlbJjswE5Cb/VRYu9HNIveJRidzSSdooEkIoRL1tYyfkCkLETq j1Fh7BXw55iS1DnlRRNlQmrmAAjQVtYr1AQS5yyO2nE5G9nIEpUcg+aGv9WtasO61Mcw9xGb 2ttPTt1ut1CWDWsGDvB1RXq6heDzTZxINBvAWTh9nIgCWQ46f2AU8Va/APOE8m88yOBXaFmY mnj85bAVxJi5rytq3+In/UHYSLOvkewrJmGIRsJywEqCd9bJ/966JCgGVg04FKU0zyYydI22 59fO+BG791EA1PjPV8Eyi2yQvkeZvR5MFCwPW5FOUJawM8iPb836LbT3uisU1BwUX1GDxX+J +rR2m2Sd8FcCdf/7B7rENLBzDE240Qaygb9QYaYQAq9xdCL/Gze84g6L2eRWUo40TbEWOPNH qM35mRn3jbO7R3plRChuxsJHc094+/FtBJPzLwQwJWN5Ur3ue8PQrlXW8YlkRZ1IfSqrOmHd x6I4j6yVrpu9R2BwrtM/jWBOMfwxPqTLoM/v3rhhK/NNeWytwTHnnypL8w3c2YJA938W/4vn cAcNN8PE/s8+9WAbAwSBJ4wnTs7zpsNiY5oGxrmNJplMTb9JWQGLm3JCKqk9fduJdqQKh84C eQ6SyN0IZRfm1QTz8grEsN0eqIvXi4qgYbz5gjZhgwyFnVybzLXonqw5VzMunThNhHsL0d7n Mu37covd7437DL5/XkOaxmfwqxElWV3/caL9i1uegp7O3eiwyLe3YSUisAhocfI7zbitNZod A0i2NJDB6wY3FwOdcVmDbEZgpLrFgvw8uyGOXVC4s3XnxjwZWBW3lNTc42i87XUjtr1uWljr I00/eEUgzvb751HKR8V/jtfN0KiS9npZAhLMTMmHO5Gs8HJKL6LaHYmj6HL+8ApBRLthXP/8 X9gJRAfEIs7X3sq7SYYRoQzaOBWGT2GrlnOPlOPPiP+gN3BES6SjR30HyXAs48e6eMQfbS5+ kdZOdwh7I9WJ1P3wPKIi5STMJrwpqA+0Of4oIipkIhFmGbUOkVHKDSSQaS/Kjkhjnaej0DeE ryZ51HopRdCA6e5Kj1VSiv2dE5Ys1E7G+6aUbgbYwiUgONHj1yg7ItTEUqrWDdh6Tk4nFeRo uwCA3z19X6S7Wqps+CIbTpYKDFYkD3UPzDd0ck5wRhwQ3IQOyRoXhkIpJAhfmgieFbKuqHO2 fy6MnF3IQsfHXChfpa0kUrLWV7hAn4ildKPERNOSqfDy5dvJLGq22TRPPhciSz+Qw9rE4fiN sy/ZkxH303YGj3I0umvEX3c2M3KV1V/JJXx89VG1gLl88iOcOtsrs4s6/0Oi8VuBb7/q3zh1 egINDfXITSoLAG4O5MYamPeud9dpztAvF0Gh0vu/vaEVWjllqlcllWw4dNJ1srhTzDcKqi3O XJFqk7RsX9kW1yuvsJD2NTJKO7y+vm2zit12+0TJbtHuRi1XvdbvyF/ok5ItMfE/Qw3MREJr 9wuhZyDGzJJ7XhPdg6jNyUrd9iKi5Stgu6TfRNcfSQ5z/0l6UjHECciLhZRiP2dI+W7winIf 6ASDLMitJMj2VRGkQv+R87BwYogDB51e+VT853trShq1fDaeM1MzGBtVNPRLNzmDa+JdJZRj kq5z0M2+nPnFM/QftTfZVM3qgxyfOJfMavsvxQ3vojKURzsMr2fLvgrhdodTHri2TkedIKvC cN3KoZdAC0Fzy/sazR5UG7Foh1ak0FSv6KzVcVtL2415zSd6Aj00cwqGw+dF78I9tFhpgNY/ 3Qato6cuyN+MBV76NXWhvdmdKkQjhz26LWt+UgHln68hHeF8ozPY5ZKzE4RgLSBsXs+EAndG UreCQqXoZqNfB6FdVK+xfq9XttQcI3RNdgUYP6hsvXPWbvuhywPsav7NmB+3rQHOVNrMSoFA u0iLQtw3RacRF3hi1rJE57c81xlkUSrw6jiJUy0buzy31U6q/Yae4eOFBwtma+woRLyEM9dG lX+iq6IRhWqD3V1i5aUSAxQO1u22W3lPvdNh/8cwi2F2aLk6zUNpSwYBciPHzRVuP+nyUgIG Zw/fyQlsepo7+Cv7mwMbqMrfARq8xgfOtPfW6TDdcLkHWcgcOa9BFmhBzuQgMetgt5RURvSh 35/KGyv0GC1mMJDi3ogEk5CkQV0TStebD5P5goE63EKYZAcydFBpAe4Y+7Yn6II+3WH2jJJI ZLALsUCyAwnuleeyWKlhxGaT9xzyi01lUiKYPynE7+C55BKHNCijPa83zTeeaMW9wY+Vmq+M MQEn4Kdq3EOOgY88GfrCQkEpeULTYW8aRSTQKms5dsaPW2cmaflQ4Yn1xGiKvXrquSEtZFe+ u73NvEuRC69j8CZnGoEje3mu31K0nBwk9KspdtajI04IvFJfL7I7dk1kco0UXXjvDLBVl+LX CT+cORyaj3BzFyCnY+STWrSm02SQ1FHAjTHWFfn7yejvnBl8sjp9RocsB8LuIS8MiJe3J3Hh 5Xzr/qeE/G685h563N2p15Hjyf65BU7vZCfOR5R9URbVHewz34i2sb+ufukFW1vXUFalQ70z +WA4/t5qs4quCAfoJ71GQGJKL7ZrQaZt66RQ2ZVixLhJsmhOFlBqab2l+zoWI2iQ2P9U9CZx fRreUoAAxb9+cOYMhmgN2jJZvXQ+/9NIAbyUjLeNfIteCxsfpstKvKfHAR6WlUvZWn4cDaz0 b6SNUkXLHKOTZvwhnGW/KpQOEcY7+t+wA2AEQn7tq4PBPSH1VrBvBEF0nJOqGMHjtQKH630i WZvVno0UZZj6of71QFN7JcsHbMO/hv262F+dVA2lpW+QrlXq/bmu9DY4VmJmxm1dSQ++gfmZ pt1uPWfuTWxNf4rD1YGh1omC1PetZBW8zGYonVTU6CaG4uQIgAKmKZkVc15pqX5CHCw1jdXj nRUH5nI8PuZAl/0vW+r1Wo2m5eHKLSRleglTy9S1DvCNa7nXkHvWY/7hQMxZdDObditl79E4 d5vr3R8kSta+8/vlwghoX0Wmmnv9QVSBzljA/HciJKR+nTfqx0b/DqIz4f3DZ4hZ+nsN/oMv vKYnpUizzMqCppy8MRIQ5SqRzpl1NtpdIvbRXmOYv/eQApxxsGOFcG3veDVh6fVmiB4unUa+ RHgciAThiMuEVkJApk1kqS2vGdwH77q/6osQu505it2JL6s2ZWSFMouXg5J2wO22q/M9nadc ddRZoJjgWmNx3dUyTqM5hvJlO/zihzOyxqp2aFCvy6FRI3IItR5qQZkaoEbwkqlC7PBPDbZ4 oST6XDH7M0W42mqONucfTo4PCIL/ZiKskBBAbVV08Rf2XSz3YXW18x98CX/VN9bOOq93EH8t zLllKUAIolzkKFefSAemGB5gZZeXxprbiX/V6f0AAxujrJybBVzlEH4cTRTIXc6bJIFxqfnh dhzIiwd616LyiY/3Wu2csqXSdfdnCiGwWi+cLcb2XdepsZMIQ5pG9DSH7RO+12XvC5V4vwmf Wr72xhlKvJP2URU/ckESTpuQYxu96ic8G1TxyEhCmPN4zpNMjIdXd6M8k0/AcpIGVultRQBP i1NacDDjktxzbiP6E+Ut2U+8ZCjY55JFTxWOxzPPpxzmafAbhHjJ8CHnsmsmkf2BE3j8jEkE Bdra3iK5OsWBJ5VKBxWoPSpD8yv6Sp/2WV4cB2uxz0eZA3nemUQqHk3uWFG1c9LFlPaODlym kgDzrJ9uSDQoYjwgRG2b1ocw+v/SYXMUu5gPt9Lfk0tULCtvrxNm08jgwOc9U2mGUcPK4g7U hwAzX/CMX1NN/DKfItotrp1RF+t/izjiv7akZfanypwkA/VCzdLaDcr8xa1WQxKAZryaX2aT 1jnGTjjjPJjg/70ugbzs39T1Se87SSwE52GlOl1iGSdfXZA9HGnLz/rdHbq8bh2sgGCLrLKH yJzlMsZ0L8gZnjpqbjZ16sObmvodfNqWQJvcawoS0BVY1VDKLgg+666jou6JXtTpUIAGzTCg KLGc25q/biCj2uqzvIpcVfzno4J7fRi8SWMPYSxstyGpznb6TzXHZRXsoZhCC0FFY6EDUQoC YCynpbvhDU94ROfLqLmv8WokCHgzn0jnwrLroRVHA2E3qEopPGQ//quYPfUF6IDDpOEVg03G 96MMDxJWfHEz4YHj+8sc9I9Pfb86u2Vkslz80p2zSWEspu/lQ+m6if5JOUvmRAU6dW6nGC/w J/ZzhKXb9w17pAQIoyxO4jAueKOUhreSlAZDIOVfTb6yqe3AEyFSVd7hYaVXJlTQBCNBwq38 5LgGQSDcjNjqeMT70vbyPcIZXV4q9gAhI5ImOoN2ky/ny/Gwq/njOMZSFcQe1T8Z0XSmmPqD Io1lE+kMaIO4Q73bfgocNzsV01CLWg+zfN2HKDn1RLlCcNxhIkBRJ1zjSZiVJD7P+OVjBQGc luuyQEXvfk5aNlI9GejxD2SJAWe2aOksAlJHZplubj+PtjVxATmH2VHXgfSmwsrQFPCJYhOy tAHmOb8m8nHiDxV2RUC4An4BJr3E2Vjd7b8tBQhfbSzg16tYtm8BCVidZv3QzCtD1pfuGIzU X9OY4mSkmEJ15pxLN3PCezNhKeHLW+oz1dGNiPB9ThUYnv3OsJcXaAs18jRbm5RLJlKpUHaA /bo7y6QEbFEp5Fcl+RtSEI54GgrvDfB9BEMPeJnE/XpMDJm8Yvbl1RaiSgl8EYczVsvy6jOf GUIWUpkr6JTRCHZBNONKQetnPxsmVq/HxBfvm9GkFsZhNuJYVuNb8634ju4b1xlwojKygj07 kw+oPrqOPZ1URKnbD4UnVWNd4vE3bnc5TMzZN98FOkYaY5QFmWxhuFQf5FkjLBlmy0Q+ytFa eO7ZbB+o3uNd/iKylK6fXZZmmQb1fgsrQ37P70pTxZsXH7dKaI34t7LkzMqdF2oMX/ORGYYR VafK1I465viHE1Oz+SoHGl9CCHnoE9DqdKz9+hTy2AXpMCYxqebQdGExddWmjEG30XpvaDGx WetXwuUEc73URBpCfEzF2hMiDhzSSrUzpUTZjIEW3w+FkbLm7AqL2yNHJYe/XIO+HFscUKh4 mcFJFaaTa/yEm+mbjdvX/h5RK+NuTTZzhAY4YO3/bA4hEaPAmp9g2Yeft7OetLJPpJ6tbck+ K7rynfvuJ9b4phbISYeQdMeRS3sLXjtW9VJquy8USYuBMzrWSFYihveAXt5WZfTOuytG5MQW OVNyvhkZVOtxnw8GrIJUoj7iHVRHU9nCDuyq6iqlwG1D1/Br6KOOUqQoxpPBd9jYqQr2oqnq 0k7OhCN2x9aty/xprwL15uPM/s4Y/0L3z5RIjcZg0piODzJBi+x9uzrlWgQ6oBEbfINo8jzd 0OoAmqDwKucccIN/+gbqe2Um01GnBHvpwLbCRSUcwk6K42rkWk9w+JBsMzbshqfCrh4Dcoly +ig8Z2Us2U4HiL5Ax4A1bECzihIUs7YzV5um+v/R7dauLztnmLHWvAHQscJ9fMImBCEECrM0 6C+FN1c+a+TXmGQYqBQ34VUhgG7lmsIcCC7eHFzldcTbuZ8AqRXSVCU+kHtg59GbigOc6kQZ Ud1cTYxx3MuhOO8sIgZnVoIfddHyTHarBDxsiQ3kMMg+I7Oro2XNwoYPy8X/ZRHjJ9ND34Zf ObPsx94i3OFRAKTwPoYGFm0wtTQS82hPdKAsqdtFMRS2tXjfzUQk8FV9oKdqi/9JIZAn6aBi aIqV4G1Y8KV30bSQHKHrxdxQH901Rjr5Y/mTmPlnev709LT+TUYuKUwnjZr+gnFQaeuAH890 UY3Re2yL5OlZMKZ+0Jz81bZqzVimt1PmRbjLUzT4f9M9U6zWXuBOV45KGtYQyBSL6pCoUXXV JL3/Unshcf5qc6C5kbKhROLwgY/wS2fXHvi8Lzo/IYqvTLvGgIsHvXy/p8ghqsnzE9b1JUjY c0qmaQYXwK/YSf6eYe6J70jO1XjWEGzq3xZUuJ+p+2yc7LPyt0vie4ZM3uj1dXqdq8+0h9ti TXk4BiTuLoGRnGvxGRj7NuxtpVZNX9CKCue1J/i+UjEm3nZ82Cf6uGPexImaB20t884Vd6fH 44W0ZePRnvSuj/MujsOppY0UnP5c//P1IEez4nuDiFIKMqaMTm7rXtAEQJQoCoZ6e9TZPDvU TAB2z5ewgKgOQ+rzcOgPavGYDsfN+Dq9cc93+as7TgHfZSi9VDyN4LZsBBd2viPSAjz4Rwgf 653kCXnTpwE5UkbPwFmYAwzbwY9pmTb67IjNq11vl3bzg3oN45FgJstt5NhuZe8l/YWRWlSe RAh5JDtJS8sDtKBAIr7cgekuWjSdG1Wnjcv6SPRlo8z4D6p7QBeBOw2VsKZVaj+xzrqecSFQ pCJ3hUjcLfhAcCtqsTTltrPVR325f5lBJXRZSGghAWjamHx8Pi495+cOpy9ndEvAOwJwtftv pfk0KDd1cklP5oDsa0TWtDPGbN9sGc1WywGhV/mjg5wHE7sqtxQKtSavy7HUmBahxhnLIUh9 NcAod9Fhu/VwGaK6VoaKiYRzu7avfVjXxzsDx6ZCAZhV5mRiQmd5WbSzZcxvuAXdhIGlXQML ilfIMUWaYPljjrjogdWw8RXpWptq59YFty1Hd2E7AqPSpUwk1Ya9kLne1h+JGu4eFMZ4eOmm 0Bqvis+8hzUfx0Janylnxb8hEnFJptplQQV8OKREplDDxWmGMRRb93e6RKDONyyAbRjR+dB/ T+YvbcmTIUbR7S0B77/kxWRv/yAGmgSEhpbnR7sNvVQvkMas2Z6RWydPjmNdBHQuj2FCXh1s CwXtA1ryradhVxbFb1YCXqCGHGMBEc5AupA0M1a+lrFj7FP42cAZixl5M7yJh5x7N/QYxNqx a8pkJmL/Fv8HqZENMD/6K9wHbcH/R4MBLWFpBEHcWc8JQbnSfwQ/oLxWp3XV/t5xxmlY+BUb NlrfIbK4sJ+neaJdFLKe+FMjyFW1MzzjMdtIRFjWF7FAMjzR3lwqyg1jQC9hZ3RM6aTEM7d2 iUtVOOoIOgbYyLX/aZIrAVho5PhCsQDOJjASjvPG0D2X/o2xPMKIN419SWLVSBML8gCviwGa IjKDF6JMRc/KdbzODb0A+Oi9fU8ArzPnNzIbQ/FAPPcqPgW8y3wFSAw9EH8P7FGTevPRR2Ap bSsKMRbuj5FAW0cVuQ6IDMsedX/EX7KHAFJUR1hGu7PRQq89K3UE5JXCmV3/QEbsoNrvg4We fZ9jYaKCcWfeuj0FpnyjIvEwj4ACsqiQciTFsoKblTwdaVvmgRuw3Y49KKq8uApLU/bWFouL xrkbkpnA2Y3bDNRqCRVo45enKwTroccw2ehV7rmGgpv4vwKKXO19V0b458jQchTejMrvIwJH /6D+4wiw5O4pXi3KOEuLqwLH3oosn+S7lr/c2W3UVokLXVDPHMssN1Zmb7XLIjQ11ISWAxRD WNIELveTIEFNn/t/lhWZobVBQPm8PgsYvrIIjRIqHGzBCJuOjjv/8A/VHJ/c9yhaRaZe8SrT BBtvH5A8tmYF4DLBJQiKGK0KIwmwMxywJND8Ffjl5dUm5Ya08C02tzz/lON7leuFEnN+izS5 MHyhN1Yk9camvdDwMGV1x/2s3JDF8hCqQzVaFAMlh36mKZAOd0vGhxirnN5aIsf0Zi8u1r9C rYYdjqB1TSGKJw61JyVaFJcKKS1kWqasLXhP1fQvVIGhw1X0TJGkogf/8a7UBKxDnhARDgXT BqnMYLKlpFj47nMf4NEYuPzrESxbCzc1UczmvVbAIV5ttw75pqRg+vqSrttm+XWP291suXXY EHxSZFwBGF6aEOOYCp8jCctyowgVzFus2CTaF9aealRYXquymY2pi8ysHwD358vJQTIHOY6s KuQ34VtFmCvhzg3ZniXuxCAQmIxx7UjNFvFPMez/ouKjRglvF/niJ+7/pgw89B61Rx5LezvH l2BWAl8zz3Dr0pez82zf3z1PJOnue3Ww+3TFQWhrDb0M1TbOf7IfHscFvgsZjEVIC+QAYUza 1F9rHNUvCWZzf285H7+IZSnG0DeWx3IQkcHPCSJRWOIIXV1Wb3yM4fvvddxBS7NB0pG9z/fS fMbqWgf4/A51MaZdXXAMjcE38YeU2T5GovewHzM4w2N1ZWyD2+1KvXZ7oJtLeP2kf3zxND0a qUp2o5smmLyaks6SkjNm87BhypqU4zft9M86g7nVcj2pzzWuKikDZhxJBH3FxHLXi0SmreYC jqkXWOCyrP88RlCSgCDbV0jJ8pg9SjEhJGh+kVJVdI2tGY/fa1Chr8Ozzqm1WPx1z+68YMVw a0SB3TJ1e3iG9J/B52LsdMxgrSGfMrMc+xvyNms2eMd3Dg8XROY9sDOic0CrB+DpgDIMkekB xn5wCB2C3TOn1KQCdMLnqjG5HLUssEB7hqFdml3LAN4WlcKOgMn3waWeHpoSp/embU3zJGMK ueMUcrJatTlpOqvqk6kkgDyHJRIwBDCrPopR5+aJ5mgVrz35M8M08gOfdGCucc98FJpLqarH y31pGXgccj/NYw6h3y5ig8BUWUXD+exj8GWClSjVlrKJefEx90NEMMsjb/ODnzeQSf6yDEty krJSqINTCQtMrCNkQ0Df9dA30nWDRHjYPqkOb5o1N4rUL1NGFYr00+N+/sUVlG9sPIzAsrQ0 NAqVKb1+JnMtvJo5uUY4U5+OJrjBECafIkJ5HHl3Ivn9A8Tz2V2WkEySMxzA7evdn0/cK9WE fXTxhOLbatBd4zPCvqstN0RHgh1cWeqU5PrYTXB1TXqDqKjQko0Kt/NqsE3a+ICuhsXhc7zX 0Hh1kjHj1NxiYVp+FrNdzWFqtosP7rsIOsVtjBwS8vkhXEWtQJEspoxLaukGUTYktmHtkvot BB8do0DNK3EpVgTJvBOwYWAc8r8bsSCzBtgxJf5IGBCdhlHPaE65mEo0okZCiydbWIa9RdWd C+CzMvw9U3USom6F/dFO2GyNPtwjWz/eTYb8LBRlAHZw4Cd6PDFS4Y/oX2NJMlky7Frrlq6Q G9TM6jVVIKgEBPa8SPgcimVTOOz9ulx5iPbgBzuqa24+NUmP6UoJlfvfRHuEJMDP85S1tULg ZC59evaaq4+BfJwZbX4BVPa1OF8HJTa1Voitva9LkN6A2mf3zx1g/h5C+ljjvrNpDY6ra+DD 0oQBPR+jyLeFPOEEFmUWlwbPY0mCeVJXEBF8qrDtf1xFeeh3jgGvAKNjqzTyjHIR9st5GLGF XFKHtmgRCbuF+JApafNdAjkcRvNNvmNyyMRBd8cLYprL2gDerZrpvK6tN3B19CUGyQTT2lST /0BnTiRqkB36zcClde8/3P9OIjU8j+Lmf6HbKFXTAjrjQOyZMMkhxn5Pv7z6mKRSPsfGf/9S TGEM5SFpBveLpzSNsv42znXHFgKux8o7Y988wJpP7ALynwERegh1b3VveA4efgyMwXhFdbVC lybCg1abyU9fUUZtmSONnTMYqZnQjCOc6UsSISYAeO0YweBPIPwQp8qvC0A4Iw6qEAjBiWYc F9/7dSZKfA4sA7ic8vdXZRtjhfqb+/QlSSdeiFtZ638dhZpslnxrrOyWCkQC9zv5ThE1c+hq 9gjgnzjc1aqhTcNgOo4dPSKRHGSEK1bixnOSMwNr2we84tNGyphKUZekD4uOEwYY0NJ75CnO tudCWdCoGNDFAKx6ySH9tODWM0upDR0qepLdNbId4nRLjwAAAQACACAgEAABAAQA6AIAAAEA KAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAMz//wBoV1gAAAAAAICA gAD///8AwMDAAP8AAAAA//8AvwAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiIRIi IiIiIiIiIiIiIiIiIiE1VVVVVVVVVVVVVSUiIiIjRERERERERERERERSUiIiI0RERERERFVU REVVUlIiIiNEiIiIREmZRESZlFJSIiIjRERERERElURESVRSUiIiI0SIiIiIRElVVVlUUlIi IiNEREREREREmZmZVFJSIiIjRIiIiIiIRElUSVRSUiIiI0RERERERERElUlUUlIiIiNEiIiI iIiIRElZVFJSIiIjREREREREREREmVRSUiIiI0SIiIiIiIiIRElEUlIiIiNERERERERERERE RFJSIiIjRIiIiIiIiIiIiERSUiIiI0REREREREREREREUlIiIiNEiIiIiIiIiIiIRFJSIiIj RERERERERERERERSUiIiI0QiIiIiRIiIiIhEUlIiIiNEOZJEQkRERERERFJSIiIjRDIiIiJE iIiIiERSUiIiI0Q0QndyREREREREUlIiIiNEMiJ3ckSIiIiIRFJSIiIjRDRCd3JERERERERS UiIiI0Q0QmZiREREREREUlIiIiNENEJmYkRERERERFJSIiIjRDMyIiJERERERERSUiIiI0RE REREREREREREUlIiIiNCRCRCRCRCRCRCRDJSIiIjQkQkQkQkQkQkQkQyUiIiIiQzQzQzQzQz QzQzQyIiIiIiIiIiIiIiIiIiIiIiIuAAAA/gAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH 4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AA AAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB/gAAA//////oRzoMEABacD9QwPA BcM4niYooxADwfgQJf9/hwDDi0QkVQQS6VXs7FEHU1ZXM/8xiX381BUcYCAoi/BoyMA3D7dF CFBkViYYIdhTkRUUMlAOECE7x4mKPHQqFhEMDVdogKzAagLxsBIRQP91bAyKNAiIg/j7v1QB dQQzwOtB0Ns7A/d2GOhh/xwCmbkbAVLx+YuAjDAUA0M73h5y6I3M/FfhdWwIfXgEii4JEWd6 ObH8D5TYX14pW8myHIGMZAx8VnC+YAQMV42FnG/zoqZQamApFSysDT0oDYgs4PtOjNcUvEb3 AIB9/lyLNSTFPb/gReF0CiIlVwXWIQpo0LAvHYC93IlcoUI8ICH+NeGhORA0YTAJamXoMrv+ EFmTP70Kg1COyiaRIEGwBq9yRAhq2wUoxEaj5B/IFjyJPbcjLXRTFDTobEV2dSLGAxU4NXxQ UVoSCXVYloUSwHQFVE0TRhUjNBEUdRkPagHnMEgSAvTQkDEwwhAAtDgwQDKQCXQkEENVJ2yX zo5pz20KYQifdo9lIO9F727vY+9y73nscCtl/GTPJlftbyObTEQN1i/lFhTNMGJKnwpT2WtZ TrMnXC7zQ/NadjOoMXAq/8OFPDVkpy64Uw7KRoGfZ5loFXP5QlSRDoRrGQN1+GVy9m8AbmZp Zzl4LmRxbOEQQklOGEFSWRBGVgNQcm90ZWObLqN4tjFgXAAA4AHgAuAg4hDOEQQN6Ba+EX2k Dnsog0YiAYwoCRCJIBZJiRTAwp8BFYADbwgUB5ACZhPAAtAQCXBV/wO8CFIHQQIGEwqOQigB dwFscBAon9EECBB5mYP0RPf9JhAihBDi947QAhCckU+9GAjwqwEZ0g+PA4BceMBUB7ADrQRS AzjqrwAAAeAgcEAOS0VSTmBMMzIuZHFs4EbobwZzZUhhbhjtwFpyPml0OkZuFb6/KWELHEEd Vp96R29mUudzUXVyY582Tzqpaw1iYWQWEElpbrZueko9dE2+ZClsXbMiRvFweUlSm+R0RkTA JFfBa293c0TfPuRj+ep5pTmgLRROYW1MhlBy8PJk45xMc2p2H0xpYjtTLz5UUJNDz+5uNA0Y TGG8RXLcXOvFjE11CHjMTgMAAAAAAAAAAAAAAAAA ------=_NextPart_000_0016----=_NextPart_000_0016-- From herbert@gondor.apana.org.au Thu Jun 24 14:41:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 14:42:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OLfrgi015780 for ; Thu, 24 Jun 2004 14:41: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 1BdbyZ-0003dV-00; Fri, 25 Jun 2004 07:41:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BdbyU-0001Dc-00; Fri, 25 Jun 2004 07:41:38 +1000 Date: Fri, 25 Jun 2004 07:41:37 +1000 To: "David S. Miller" Cc: agruen@suse.de, netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-ID: <20040624214137.GA4620@gondor.apana.org.au> References: <20040624123603.GA1241@gondor.apana.org.au> <20040624124654.36b31815.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624124654.36b31815.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6319 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 Thu, Jun 24, 2004 at 12:46:54PM -0700, David S. Miller wrote: > > > I'm having trouble understanding why we need to increase alen by > > two bytes for NON-IKE. As far as I can see it's adding two bytes > > of random data to the end of the packet. Is there something > > obvious that I'm missing? > > It is intentional as far as I remember. If it's any other length, > then the other side implementing this non-IKE encap stuff won't > accept the packet, it must be that length. Which impelementation does that? The implementation in FreeS/WAN certainly doesn't and it has talked to many commercial NAT-T software using NON-IKE. There is also nothing like this in the draft for NON-IKE. Even if we do need this, we should fill those two bytes with some data. 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 hno@marasystems.com Thu Jun 24 16:00:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 16:00:53 -0700 (PDT) Received: from filer.marasystems.com (marasystems.com [213.150.153.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ON0kgi017582 for ; Thu, 24 Jun 2004 16:00:49 -0700 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id i5ON0fO27102; Fri, 25 Jun 2004 01:00:41 +0200 Date: Fri, 25 Jun 2004 01:00:41 +0200 (CEST) From: Henrik Nordstrom X-X-Sender: henrik@filer.marasystems.com To: Paul P Komkoff Jr cc: Linux Kernel Mailing List , , Subject: Re: [RFC] How to implement wccp over gre tunnel ? In-Reply-To: <20040624194039.GA19574@stingr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by filer.marasystems.com id i5ON0fO27102 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5ON0kgi017582 X-archive-position: 6320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev On Thu, 24 Jun 2004, Paul P Komkoff Jr wrote: > Currently my goal is to make squid + wccp configuration working > out-of-the box. Ideally - without any extra modules. This is possible with WCCPv2 using direct routing avoiding the need of GRE/WCCP tunneling. WCCPv2 patches do exists for Squid-2.5, but may be a little hard to find.. (no official maintainer of the WCCPv2 support for Squid at the moment) > Currently, most wccp configurations are working with this module: > http://www.squid-cache.org/WCCP-support/Linux/ip_wccp.c Please note that this module is by no means clean, and lacks a lot in security. There is also a WCCP patch available to the GRE driver. This approach provides a little more security but is also more complex to set up for the same reasons and is not used very much.. http://www.swelltech.com/pengies/joe/patches/linux-2.4.8-ip_gre.patch The GRE patch is very simplistic and would do good of being properly implemented and integrated with the "ip tunnel" command for configuration of the GRE protocol (normal GRE / WCCPv1 / WCCPv2 / whatever...). > What do you think? Which way I should do? I think approach 1 (decapsulation within GRE) is most suitable. It also provides an adequate level of control on security and permissions which may be hard to accomplish if separating the two. Regards Henrik Nordstrm aka hno@squid-cache.org and current maintainer of the Squid ip_wccp.c module From anton@ozlabs.org Thu Jun 24 16:24:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 16:24:27 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ONOPgi021416 for ; Thu, 24 Jun 2004 16:24:25 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 1EA072BD71; Fri, 25 Jun 2004 09:24:19 +1000 (EST) Date: Fri, 25 Jun 2004 09:23:11 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Cc: cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Subject: e1000_clean_tx_ring Message-ID: <20040624232311.GG22495@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6321 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 Hi, I was looking over the e1000 driver and noticed what I think is a bug in e1000_clean_tx_ring. We wouldnt call pci_unmap_page on tx ring entries that didnt have ->skb filled, eg zero copy packets. This is on latest 2.6 BK. Anton ===== e1000_main.c 1.120 vs edited ===== --- 1.120/drivers/net/e1000/e1000_main.c Sat Jun 19 10:00:00 2004 +++ edited/e1000_main.c Thu Jun 24 02:16:42 2004 @@ -1070,14 +1070,19 @@ for(i = 0; i < tx_ring->count; i++) { buffer_info = &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); - dev_kfree_skb(buffer_info->skb); + buffer_info->dma = NULL; + } + + if (buffer_info->skb) { + + dev_kfree_skb_any(buffer_info->skb); buffer_info->skb = NULL; } From jt@bougret.hpl.hp.com Thu Jun 24 16:43:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 16:43:13 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ONh9gi022114 for ; Thu, 24 Jun 2004 16:43:09 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 735B616D7; Thu, 24 Jun 2004 16:43: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 QAA07995; Thu, 24 Jun 2004 16:43:14 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bdds3-0001YD-00; Thu, 24 Jun 2004 16:43:07 -0700 Date: Thu, 24 Jun 2004 16:43:07 -0700 To: "David S. Miller" , Jeff Garzik , Andi Kleen , Pavel Machek Cc: netdev@oss.sgi.com Subject: [PATCH 2.6.X] 32->64 bit conversion for wireless private ioctl Message-ID: <20040624234307.GA5514@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: 6322 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 Hi all, (Sorry for the spam) The Wireless Extensions use a bunch of driver specific ioctl. Jeff told me that those can't be safe when running a 32 bit userspace on a 64 bit kernel. So, I did a patch... Patch is for kernel 2.6.5. Treat this patch as a proof of concept. I don't have any 64 bit machine, so no way to compile it (without talking of actually testing it). But this is where I hope you guys will help me ;-) Waiting for your feedback, Have fun... Jean ---------------------------------------------------------------- diff -u -p linux/include/net/iw_handler.p1.h linux/include/net/iw_handler.h --- linux/include/net/iw_handler.p1.h Thu Jun 24 16:27:53 2004 +++ linux/include/net/iw_handler.h Thu Jun 24 16:18:29 2004 @@ -412,6 +412,9 @@ struct iw_public_data { * Those may be called only within the kernel. */ +/* Data needed by fs/compat_ioctl.c for 32->64 bit conversion */ +extern const char iw_priv_type_size[]; + /* First : function strictly used inside the kernel */ /* Handle /proc/net/wireless, called in net/code/dev.c */ diff -u -p linux/net/core/wireless.p1.c linux/net/core/wireless.c --- linux/net/core/wireless.p1.c Thu Jun 24 16:15:07 2004 +++ linux/net/core/wireless.c Thu Jun 24 16:17:07 2004 @@ -301,7 +301,7 @@ static const int standard_event_num = (s sizeof(struct iw_ioctl_description)); /* Size (in bytes) of the various private data types */ -static const char priv_type_size[] = { +const char iw_priv_type_size[] = { 0, /* IW_PRIV_TYPE_NONE */ 1, /* IW_PRIV_TYPE_BYTE */ 1, /* IW_PRIV_TYPE_CHAR */ @@ -415,7 +415,7 @@ static inline int get_priv_size(__u16 ar int num = args & IW_PRIV_SIZE_MASK; int type = (args & IW_PRIV_TYPE_MASK) >> 12; - return num * priv_type_size[type]; + return num * iw_priv_type_size[type]; } diff -u -p linux/fs/compat_ioctl.p1.c linux/fs/compat_ioctl.c --- linux/fs/compat_ioctl.p1.c Thu Jun 24 16:15:18 2004 +++ linux/fs/compat_ioctl.c Thu Jun 24 16:24:34 2004 @@ -67,6 +67,7 @@ #include #include #include +#include #include /* siocdevprivate_ioctl */ #include @@ -3070,6 +3071,79 @@ static int do_wireless_ioctl(unsigned in return sys_ioctl(fd, cmd, (unsigned long) iwr); } +static int do_wireless_private_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) +{ + struct iwreq *iwr, *iwr_u; + struct net_device *dev; + struct iw_priv_args *descr = NULL; + __u16 iw_args; + int offset = 0; + int extra_size = 0; + + iwr_u = (struct iwreq *) compat_ptr(arg); + iwr = compat_alloc_user_space(sizeof(*iwr)); + if (iwr == NULL) + return -ENOMEM; + + if (verify_area(VERIFY_WRITE, iwr, sizeof(*iwr))) + return -EFAULT; + + if (__copy_in_user(&iwr->ifr_ifrn.ifrn_name[0], + &iwr_u->ifr_ifrn.ifrn_name[0], + sizeof(struct iwreq))) + return -EFAULT; + + /* Wireless Private ioctls are different from regular Wireless + * ioctls, in that they are driver specific. Therefore, we have + * to ask the driver how the ioctl should be handled. + * This is a bit messy, see wireless.c for details. Jean II + */ + + //dev_load(ifr.ifr_name); + /* Lock */ + rtnl_lock(); + + /* Make sure the device exist */ + if ((dev = __dev_get_by_name(ifr->ifr_name)) == NULL) + return -ENODEV; + + /* Get the description of the IOCTL */ + for(i = 0; i < dev->wireless_handlers->num_private_args; i++) + if(cmd == dev->wireless_handlers->private_args[i].cmd) { + descr = &(dev->wireless_handlers->private_args[i]); + break; + } + if(!descr) + return -EFAULT; + + /* Compute size of arguments */ + if(IW_IS_SET(cmd)) { + /* Check for sub-ioctl handler */ + if(descr->name[0] == '\0') + offset = sizeof(__u32); + iw_args = descr->set_args; + } else + iw_args = descr->get_args; + extra_size = ((iw_args & IW_PRIV_SIZE_MASK) * + iw_priv_type_size[(args & IW_PRIV_TYPE_MASK) >> 12]); + + /* Are the args passed inline ? */ + if((iw_args & IW_PRIV_SIZE_FIXED) && + ((extra_size + offset) <= IFNAMSIZ)) + extra_size = 0; + + /* Unlock */ + rtnl_unlock(); + + /* Done */ + if(extra_size) + /* Convert struct iw_point appropriately */ + return do_wireless_ioctl(fd, cmd, (unsigned long) iwr); + else + /* No conversion needed */ + return sys_ioctl(fd, cmd, (unsigned long) iwr); +} + /* Emulate old style bridge ioctls */ static int do_bridge_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) { @@ -3261,6 +3335,40 @@ HANDLE_IOCTL(SIOCSIWNICKN, do_wireless_i HANDLE_IOCTL(SIOCGIWNICKN, do_wireless_ioctl) HANDLE_IOCTL(SIOCSIWENCODE, do_wireless_ioctl) HANDLE_IOCTL(SIOCGIWENCODE, do_wireless_ioctl) +/* wireless private */ +HANDLE_IOCTL(SIOCIWFIRSTPRIV, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 1, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 2, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 3, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 4, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 5, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 6, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 7, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 8, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 9, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 10, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 11, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 12, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 13, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 14, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 15, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 16, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 17, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 18, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 19, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 20, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 21, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 22, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 23, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 24, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 25, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 26, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 27, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 28, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 29, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 30, do_wireless_private_ioctl) +HANDLE_IOCTL(SIOCIWFIRSTPRIV + 31, do_wireless_private_ioctl) +/* bridge */ HANDLE_IOCTL(SIOCSIFBR, do_bridge_ioctl) HANDLE_IOCTL(SIOCGIFBR, do_bridge_ioctl) From jt@bougret.hpl.hp.com Thu Jun 24 17:36:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 17:36:21 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5P0aIgi023820 for ; Thu, 24 Jun 2004 17:36:18 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id ED4031C05877; Thu, 24 Jun 2004 17:36:17 -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 RAA09271; Thu, 24 Jun 2004 17:36:24 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BdehV-0001tv-00; Thu, 24 Jun 2004 17:36:17 -0700 Date: Thu, 24 Jun 2004 17:36:17 -0700 To: Jeff Garzik Cc: "David S. Miller" , Andi Kleen , Pavel Machek , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.X] 32->64 bit conversion for wireless private ioctl Message-ID: <20040625003617.GA6876@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040624234307.GA5514@bougret.hpl.hp.com> <20040625001557.GA19939@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625001557.GA19939@havoc.gtf.org> 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: 6323 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 On Thu, Jun 24, 2004 at 08:15:57PM -0400, Jeff Garzik wrote: > > You missed what I was trying to communicate :( > > It is a logical contradiction to create a generic interface for > driver-private ioctls. You wind up re-inventing Sun XDR. Any interface for device specific stuff has to be generic, it doesn't matter if you use ioctl, netlink, module parameters or pseudo-filesystem. Now, we can debate if this generic interface should use ioctl or something else, that's a different issue. I hope you will have noticed that some drivers, such as Orinoco, got rid of their pseudo-filesystem and converted to iwpriv (you may ask David why he did that). So, it's probably not as bad as you claim... The point is that this interface exist, is in use, so we might as well make it 64 bit clean. Therefore patch. > We want to go in the opposite direction: compile and verify as much > code as possible at compile time. Strong, compile-time type checking. I wonder how you are going to do that for device specific stuff with strong compile time checks. If you convert everything to a binary pseudo-file, which doesn't change anything to the problem. Or you can use a text pseudo-file, which mean a dedicated parser or a generic parsing infrastructure, and performance penalty. You can't win. Maybe all the device specific APIs should use XML. That's the future, and allow to validate the userspace input. Next week, I'll convert all Wireless Extension to XML ;-) > Jeff Regards, Jean From garzik@havoc.gtf.org Thu Jun 24 17:54:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 17:54:12 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5P0rxgi024767 for ; Thu, 24 Jun 2004 17:54:00 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 604AB7611; Thu, 24 Jun 2004 20:16:02 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5P0Fv54021517; Thu, 24 Jun 2004 20:15:57 -0400 Date: Thu, 24 Jun 2004 20:15:57 -0400 From: Jeff Garzik To: jt@hpl.hp.com Cc: "David S. Miller" , Andi Kleen , Pavel Machek , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.X] 32->64 bit conversion for wireless private ioctl Message-ID: <20040625001557.GA19939@havoc.gtf.org> References: <20040624234307.GA5514@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624234307.GA5514@bougret.hpl.hp.com> User-Agent: Mutt/1.4.1i X-archive-position: 6324 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 On Thu, Jun 24, 2004 at 04:43:07PM -0700, Jean Tourrilhes wrote: > Hi all, > > (Sorry for the spam) > > The Wireless Extensions use a bunch of driver specific > ioctl. Jeff told me that those can't be safe when running a 32 bit > userspace on a 64 bit kernel. So, I did a patch... > Patch is for kernel 2.6.5. > > Treat this patch as a proof of concept. I don't have any 64 > bit machine, so no way to compile it (without talking of actually > testing it). But this is where I hope you guys will help me ;-) You missed what I was trying to communicate :( It is a logical contradiction to create a generic interface for driver-private ioctls. You wind up re-inventing Sun XDR. > + /* Get the description of the IOCTL */ > + for(i = 0; i < dev->wireless_handlers->num_private_args; i++) > + if(cmd == dev->wireless_handlers->private_args[i].cmd) { > + descr = &(dev->wireless_handlers->private_args[i]); > + break; This is essentially runtime definition of structures types. We want to go in the opposite direction: compile and verify as much code as possible at compile time. Strong, compile-time type checking. Jeff From garzik@havoc.gtf.org Thu Jun 24 18:23:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 18:23:54 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5P1Nggi025892 for ; Thu, 24 Jun 2004 18:23:43 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 564F2765D; Thu, 24 Jun 2004 21:23:36 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5P1NViO027176; Thu, 24 Jun 2004 21:23:31 -0400 Date: Thu, 24 Jun 2004 21:23:31 -0400 From: Jeff Garzik To: jt@hpl.hp.com Cc: "David S. Miller" , Andi Kleen , Pavel Machek , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.X] 32->64 bit conversion for wireless private ioctl Message-ID: <20040625012331.GD19939@havoc.gtf.org> References: <20040624234307.GA5514@bougret.hpl.hp.com> <20040625001557.GA19939@havoc.gtf.org> <20040625003617.GA6876@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625003617.GA6876@bougret.hpl.hp.com> User-Agent: Mutt/1.4.1i X-archive-position: 6325 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 On Thu, Jun 24, 2004 at 05:36:17PM -0700, Jean Tourrilhes wrote: > On Thu, Jun 24, 2004 at 08:15:57PM -0400, Jeff Garzik wrote: > > > > You missed what I was trying to communicate :( > > > > It is a logical contradiction to create a generic interface for > > driver-private ioctls. You wind up re-inventing Sun XDR. > > Any interface for device specific stuff has to be generic, it > doesn't matter if you use ioctl, netlink, module parameters or > pseudo-filesystem. > Now, we can debate if this generic interface should use ioctl > or something else, that's a different issue. I hope you will have > noticed that some drivers, such as Orinoco, got rid of their > pseudo-filesystem and converted to iwpriv (you may ask David why he > did that). So, it's probably not as bad as you claim... > > The point is that this interface exist, is in use, so we might > as well make it 64 bit clean. Therefore patch. You're still missing the point. This 'private_args' interface should not exist at all. Making it 64-bit clean doesn't help anything (it still needs to be endian clean as well, but even that's not the point). It's a run-time type interface when all other net drivers have managed to avoid such a thing. It's overly complex, and is a "black hole" interface that discourages wireless authors from coming together and developing more common pieces. It's just not Linux in so many ways. Please, look at how the other interfaces in the kernel are designed, and how they evolve over time. > > We want to go in the opposite direction: compile and verify as much > > code as possible at compile time. Strong, compile-time type checking. > > I wonder how you are going to do that for device specific > stuff with strong compile time checks. If you convert everything to a See various implementations of SIOCDEVPRIVATE. Jeff From chengjin@cs.caltech.edu Thu Jun 24 23:37:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Jun 2004 23:37:41 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5P6bdgi005891 for ; Thu, 24 Jun 2004 23:37:39 -0700 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id F08C1DF28A; Thu, 24 Jun 2004 23:37:38 -0700 (PDT) Received: by orchestra.cs.caltech.edu (Postfix, from userid 20269) id 089E39BC27; Thu, 24 Jun 2004 23:37:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by orchestra.cs.caltech.edu (Postfix) with ESMTP id 1420A9BC26; Thu, 24 Jun 2004 23:37:36 -0700 (PDT) Date: Thu, 24 Jun 2004 23:37:35 -0700 (PDT) From: Cheng Jin To: John Heffner Cc: "netdev@oss.sgi.com" , "fast-support@cs.caltech.edu" Subject: Re: TCP receiver's window calculation problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev John, > > I think having a default limit on tcp memory is acceptable to prevent DoS, > > but when a user increases the memory limit by explicitly setting tcp_rmem, > > that should take effect. The code itself shouldnt pose any limit like it > > does now. > > The core of the problem is that you are describing a truesize of each skb > at about 16k, but each of those only contains < 1500 bytes of payload. > You are wasting 90% of your socket memory. Announcing a 3 MB window with > a 30 MB socket buffer is the right thing to do, from a certain point of > view. OTOH, it kills performance. The receiver is set to use a 9000 MTU, but the sender uses a 1500-byte MTU, which is not really a pathological case. It would have made more sense for the receiver to allocate skbs of the right size as incoming packets are received. Is it due to effciency reasons that the skbs are just fixed in size according to the set MTU on the interface card? I suppose that the receiver has no real way of knowing the right MTU size at the sender. Thanks, Cheng From herbert@gondor.apana.org.au Fri Jun 25 02:49:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 02:49:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5P9negi024785 for ; Fri, 25 Jun 2004 02:49: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 1BdnIY-0008Bd-00; Fri, 25 Jun 2004 19:47:06 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BdnIL-0002cs-00; Fri, 25 Jun 2004 19:46:53 +1000 Date: Fri, 25 Jun 2004 19:46:52 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: [NETDRV] Fix successive calls to spin_lock_irqsave in sk98lin Message-ID: <20040625094652.GA10032@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6327 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 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff: This patch fixes the few places in sk98lin where it calls spin_lock_saveirq on the same flags variable thus causing interrupts to be disabled upon leaving the driver. 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 Index: drivers/net/sk98lin/skge.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/net/sk98lin/skge.c,v retrieving revision 1.1.1.17 diff -u -r1.1.1.17 skge.c --- drivers/net/sk98lin/skge.c 10 May 2004 09:47:55 -0000 1.1.1.17 +++ drivers/net/sk98lin/skge.c 22 Jun 2004 10:45:23 -0000 @@ -3093,8 +3093,7 @@ SkEventDispatcher(pAC, pAC->IoBase); for (i=0; iGIni.GIMacsFound; i++) { - spin_lock_irqsave( - &pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock); netif_stop_queue(pAC->dev[i]); } @@ -4773,12 +4772,10 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); SkGeStopPort(pAC, IoC, FromPort, SK_STOP_ALL, SK_SOFT_RST); SkGeStopPort(pAC, IoC, ToPort, SK_STOP_ALL, SK_SOFT_RST); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4791,8 +4788,7 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); pAC->ActivePort = ToPort; #if 0 SetQueueSizes(pAC); @@ -4807,8 +4803,7 @@ pAC, pAC->ActivePort, DualNet)) { - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4834,8 +4829,7 @@ SkGePollTxD(pAC, IoC, ToPort, SK_TRUE); ClearAndStartRx(pAC, FromPort); ClearAndStartRx(pAC, ToPort); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); --lrZ03NoBR/3+SXJZ-- From herbert@gondor.apana.org.au Fri Jun 25 03:14:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 03:14:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PAECgi031524 for ; Fri, 25 Jun 2004 03:14: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 1Bdnhf-0008Oq-00; Fri, 25 Jun 2004 20:13:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BdnhW-0002jp-00; Fri, 25 Jun 2004 20:12:54 +1000 Date: Fri, 25 Jun 2004 20:12:54 +1000 To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: 4/x: [NETDRV] Merge register_netdev calls Message-ID: <20040625101254.GA10459@gondor.apana.org.au> References: <20040313025859.GA8186@gondor.apana.org.au> <405C294D.5040508@pobox.com> <20040520111937.GA21804@gondor.apana.org.au> <20040522074435.GA9628@gondor.apana.org.au> <20040529084109.GA13032@gondor.apana.org.au> <40BE3778.1020404@pobox.com> <20040605052737.GA27406@gondor.apana.org.au> <40C8F824.50904@pobox.com> <20040611020855.GA5480@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20040611020855.GA5480@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6328 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 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 today's BK tree. 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 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== 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-06-25 20:01:08 +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.29 vs edited ===== --- 1.29/drivers/net/3c515.c 2004-03-30 20:17:59 +10:00 +++ edited/drivers/net/3c515.c 2004-06-25 20:01:08 +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-06-25 20:01:09 +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-06-25 20:01:09 +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.24 vs edited ===== --- 1.24/drivers/net/cs89x0.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/cs89x0.c 2004-06-25 20:01:09 +10:00 @@ -307,13 +307,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"); @@ -718,7 +712,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: @@ -1806,13 +1806,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-06-25 20:01:09 +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-06-25 20:01:10 +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.18 vs edited ===== --- 1.18/drivers/net/eexpress.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/eexpress.c 2004-06-25 20:01:10 +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-06-25 20:01:10 +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/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-06-25 20:01:10 +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.16 vs edited ===== --- 1.16/drivers/net/hp-plus.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/hp-plus.c 2004-06-25 20:01:10 +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/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-06-25 20:01:10 +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/hp100.c 1.28 vs edited ===== --- 1.28/drivers/net/hp100.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/hp100.c 2004-06-25 20:01:11 +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; @@ -2938,17 +2938,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); return err; @@ -3016,15 +3011,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/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-06-25 20:01:11 +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/lance.c 1.22 vs edited ===== --- 1.22/drivers/net/lance.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/lance.c 2004-06-25 20:01:11 +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/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-06-25 20:01:12 +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/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-06-25 20:01:11 +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/ne.c 1.22 vs edited ===== --- 1.22/drivers/net/ne.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ne.c 2004-06-25 20:01:12 +10:00 @@ -220,12 +220,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); @@ -506,8 +501,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; @@ -798,11 +799,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/ne2.c 1.16 vs edited ===== --- 1.16/drivers/net/ne2.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ne2.c 2004-06-25 20:01:12 +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; @@ -800,11 +802,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/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-06-25 20:01:14 +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-06-25 20:01:15 +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]); --tThc/1wpZn/ma/RB-- From buffer@antifork.org Fri Jun 25 03:37:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 03:37:42 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PAbYgi032351 for ; Fri, 25 Jun 2004 03:37:38 -0700 Received: from localhost (172.16.1.82) by smtp1.libero.it (7.0.027-DD01) id 40C7315F002FF0DA for netdev@oss.sgi.com; Fri, 25 Jun 2004 12:37:36 +0200 Received: from [151.28.136.184] (151.28.136.184) by smtp0.libero.it (7.0.027-DD01) id 40CB280C00F45D03 for netdev@oss.sgi.com; Fri, 25 Jun 2004 12:37:29 +0200 Received: (qmail 4911 invoked from network); 25 Jun 2004 10:40:01 -0000 Received: from localhost (HELO mintaka.darkstar.net) (1000@127.0.0.1) by localhost with SMTP; 25 Jun 2004 10:40:01 -0000 Date: Fri, 25 Jun 2004 12:39:53 +0200 From: "Angelo Dell'Aera" To: Linux-Net Cc: Netdev Subject: TCP congestion control article Message-Id: <20040625123953.1d42b556.buffer@antifork.org> Organization: Antifork Research, Inc. X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) X-PGP-Program: GNU Privacy Guard (http://www.gnupg.org) X-PGP-PublicKey: http://buffer.antifork.org/privacy/buffer-gpg.asc X-PGP-Fingerprint: 48CC B0D8 C394 CD30 355F E36D A4E3 48CF 19C1 5CA2 X-Operating-System: GNU-Linux Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at libero.it X-archive-position: 6329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buffer@antifork.org Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I just want to point out to you a really interesting article published by two members of my research group. The paper is entitled "Performance Evaluation and Comparison of Westwood+, New Reno and Vegas TCP Congestion Control" and it aims at evaluating these three algorithms in really different scenarios. You may find it at http://buffer.antifork.org/westwood/ccr_v31.pdf Best regards. - -- Angelo Dell'Aera 'buffer' Antifork Research, Inc. http://buffer.antifork.org PGP information in e-mail header -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA3AD5pONIzxnBXKIRArSJAJ9AZoybNpTpLxj2XPZ3IBm/zfgfzwCguu3m +XKmZTP/fvy73EM5MHOUY6g= =0DyV -----END PGP SIGNATURE----- From herbert@gondor.apana.org.au Fri Jun 25 05:12:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 05:12:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PCC0gi005952 for ; Fri, 25 Jun 2004 05:12: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 1BdpYd-0000fT-00; Fri, 25 Jun 2004 22:11:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BdpYZ-0002w9-00; Fri, 25 Jun 2004 22:11:47 +1000 Date: Fri, 25 Jun 2004 22:11:47 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [UDP] Check encap_type at config time Message-ID: <20040625121147.GA11231@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6330 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 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: My foray into the TTL stuff is turning into an all-out assault on NAT-T :) The following patch moves the udp->encap_type check from the per-packet hot-path into udp_setsockopt(). As a consequence, this allows user space to detect whether the kernel actually supports the encap type that they're requesting. Pity no one did this before the NON-IKE patch was applied. As it is there is no easy way to detect whether NON-IKE support is present. Signed-off-by: Herbert Xu PS I will be doing a similar patch for the encap_type in xfrm. 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 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/udp.c 1.61 vs edited ===== --- 1.61/net/ipv4/udp.c 2004-06-05 06:59:36 +10:00 +++ edited/net/ipv4/udp.c 2004-06-25 21:56:34 +10:00 @@ -964,6 +964,7 @@ len = skb->tail - udpdata; switch (encap_type) { + default: case UDP_ENCAP_ESPINUDP: /* Check if this is a keepalive packet. If so, eat it. */ if (len == 1 && udpdata[0] == 0xff) { @@ -1016,12 +1017,6 @@ } else /* Must be an IKE packet.. pass it through */ return 1; - - default: - if (net_ratelimit()) - printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", - encap_type); - return 1; } #endif } @@ -1297,7 +1292,16 @@ break; case UDP_ENCAP: - up->encap_type = val; + switch (val) { + case 0: + case UDP_ENCAP_ESPINUDP: + case UDP_ENCAP_ESPINUDP_NON_IKE: + up->encap_type = val; + break; + default: + err = -ENOPROTOOPT; + break; + } break; default: ===== net/ipv6/udp.c 1.67 vs edited ===== --- 1.67/net/ipv6/udp.c 2004-06-21 09:37:54 +10:00 +++ edited/net/ipv6/udp.c 2004-06-25 20:13:50 +10:00 @@ -1044,7 +1044,14 @@ break; case UDP_ENCAP: - up->encap_type = val; + switch (val) { + case 0: + up->encap_type = val; + break; + default: + err = -ENOPROTOOPT; + break; + } break; default: --PNTmBPCT7hxwcZjr-- From herbert@gondor.apana.org.au Fri Jun 25 05:35:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 05:35:51 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PCZbgi006929 for ; Fri, 25 Jun 2004 05:35: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 1BdpvX-0000qf-00; Fri, 25 Jun 2004 22:35:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BdpvT-00032o-00; Fri, 25 Jun 2004 22:35:27 +1000 Date: Fri, 25 Jun 2004 22:35:27 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Check encap_type at config time Message-ID: <20040625123527.GA11685@gondor.apana.org.au> References: <20040625121147.GA11231@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20040625121147.GA11231@gondor.apana.org.au> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6331 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 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 25, 2004 at 10:11:47PM +1000, herbert wrote: > > PS I will be doing a similar patch for the encap_type in xfrm. Here is the patch to check encap_type at the earliest possible opportunity in xfrm_user/af_key. This will allow us to assume in esp4 that the encap_type from x->encap is always valid. 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=p ===== net/key/af_key.c 1.61 vs edited ===== --- 1.61/net/key/af_key.c 2004-06-06 18:27:42 +10:00 +++ edited/net/key/af_key.c 2004-06-25 19:33:51 +10:00 @@ -1075,6 +1075,15 @@ n_type = ext_hdrs[SADB_X_EXT_NAT_T_TYPE-1]; natt->encap_type = n_type->sadb_x_nat_t_type_type; + switch (natt->encap_type) { + case UDP_ENCAP_ESPINUDP: + case UDP_ENCAP_ESPINUDP_NON_IKE: + break; + default: + err = -ENOPROTOOPT; + goto out; + } + if (ext_hdrs[SADB_X_EXT_NAT_T_SPORT-1]) { struct sadb_x_nat_t_port* n_port = ext_hdrs[SADB_X_EXT_NAT_T_SPORT-1]; ===== net/xfrm/xfrm_user.c 1.42 vs edited ===== --- 1.42/net/xfrm/xfrm_user.c 2004-03-25 09:18:34 +11:00 +++ edited/net/xfrm/xfrm_user.c 2004-06-25 19:33:51 +10:00 @@ -78,6 +78,15 @@ if ((rt->rta_len - sizeof(*rt)) < sizeof(*encap)) return -EINVAL; + encap = RTA_DATA(rt); + switch (encap->encap_type) { + case UDP_ENCAP_ESPINUDP: + case UDP_ENCAP_ESPINUDP_NON_IKE: + break; + default: + return -ENOPROTOOPT; + } + return 0; } --7AUc2qLy4jB3hD7Z-- From jheffner@psc.edu Fri Jun 25 06:43:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 06:43:39 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PDhagi009463 for ; Fri, 25 Jun 2004 06:43:37 -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 i5PDhX8T008864 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 25 Jun 2004 09:43:33 -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 i5PDhWL2008433; Fri, 25 Jun 2004 09:43:32 -0400 (EDT) Date: Fri, 25 Jun 2004 09:43:32 -0400 (EDT) From: John Heffner To: Cheng Jin cc: "netdev@oss.sgi.com" , "fast-support@cs.caltech.edu" Subject: Re: TCP receiver's window calculation problem In-Reply-To: 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: 6332 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 On Thu, 24 Jun 2004, Cheng Jin wrote: > The receiver is set to use a 9000 MTU, but the sender uses a 1500-byte > MTU, which is not really a pathological case. It would have made more > sense for the receiver to allocate skbs of the right size as incoming > packets are received. Some drivers are apparently optimized for this case. I have not confirmed this. > Is it due to effciency reasons that the skbs are just fixed in size > according to the set MTU on the interface card? I suppose that the > receiver has no real way of knowing the right MTU size at the sender. I haven't looked too hard in to this. Any device driver people want to chime in? -John From davem@redhat.com Fri Jun 25 09:12:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 09:12:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PGCNgi016786 for ; Fri, 25 Jun 2004 09:12:24 -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 i5PGCLe1008645; Fri, 25 Jun 2004 12:12: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 i5PGCL026815; Fri, 25 Jun 2004 12:12:21 -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 i5PGBtn3031729; Fri, 25 Jun 2004 12:11:58 -0400 Date: Fri, 25 Jun 2004 09:11:58 -0700 From: "David S. Miller" To: "Angelo Dell'Aera" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP congestion control article Message-Id: <20040625091158.2e84ed3a.davem@redhat.com> In-Reply-To: <20040625123953.1d42b556.buffer@antifork.org> References: <20040625123953.1d42b556.buffer@antifork.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: 6333 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, 25 Jun 2004 12:39:53 +0200 "Angelo Dell'Aera" wrote: > I just want to point out to you a really interesting article published > by two members of my research group. The paper is entitled > "Performance Evaluation and Comparison of Westwood+, New Reno and > Vegas TCP Congestion Control" and it aims at evaluating these three > algorithms in really different scenarios. Would be interesting to compare with BITCP which we have enabled by default now in current 2.6.x kernels. From davem@redhat.com Fri Jun 25 10:13:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 10:13:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PHD0gi019344 for ; Fri, 25 Jun 2004 10:13:01 -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 i5PHCpe1025402; Fri, 25 Jun 2004 13:12:51 -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 i5PHCp014963; Fri, 25 Jun 2004 13:12:51 -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 i5PHCS0H026055; Fri, 25 Jun 2004 13:12:29 -0400 Date: Fri, 25 Jun 2004 10:12:31 -0700 From: "David S. Miller" To: Herbert Xu Cc: agruen@suse.de, netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-Id: <20040625101231.6f6b2f12.davem@redhat.com> In-Reply-To: <20040624123603.GA1241@gondor.apana.org.au> References: <20040624123603.GA1241@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: 6334 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, 24 Jun 2004 22:36:03 +1000 Herbert Xu wrote: > I'm having trouble understanding why we need to increase alen by > two bytes for NON-IKE. As far as I can see it's adding two bytes > of random data to the end of the packet. Is there something > obvious that I'm missing? I now think it's trying to account for the udpdata32[] header area. But that's not 2 bytes, it's (2 * sizeof(u32)) or 8 bytes. The ESP added headers amount to esp->auth.icv_trunc_len + 8 in this case, so changing the "alen += 2;" into "alen += 8;" seems more appropriate. What do you think Herbert? Does it make sense now? From davem@redhat.com Fri Jun 25 10:38:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 10:38:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PHcLgi020305 for ; Fri, 25 Jun 2004 10:38:22 -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 i5PHcDe1032101; Fri, 25 Jun 2004 13:38:13 -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 i5PHcC023542; Fri, 25 Jun 2004 13:38: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 i5PHbnqN014248; Fri, 25 Jun 2004 13:37:50 -0400 Date: Fri, 25 Jun 2004 10:37:51 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [UDP] Check encap_type at config time Message-Id: <20040625103751.5bf058da.davem@redhat.com> In-Reply-To: <20040625121147.GA11231@gondor.apana.org.au> References: <20040625121147.GA11231@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: 6335 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, 25 Jun 2004 22:11:47 +1000 Herbert Xu wrote: > The following patch moves the udp->encap_type check from the per-packet > hot-path into udp_setsockopt(). > > As a consequence, this allows user space to detect whether the kernel > actually supports the encap type that they're requesting. Pity no one > did this before the NON-IKE patch was applied. As it is there is no > easy way to detect whether NON-IKE support is present. > > Signed-off-by: Herbert Xu Applied, looks great. From davem@redhat.com Fri Jun 25 10:39:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 10:39:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PHdsgi020633 for ; Fri, 25 Jun 2004 10:39: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 i5PHdoe1032477; Fri, 25 Jun 2004 13:39:50 -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 i5PHdo024052; Fri, 25 Jun 2004 13:39: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 i5PHdQTB015243; Fri, 25 Jun 2004 13:39:27 -0400 Date: Fri, 25 Jun 2004 10:39:28 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Check encap_type at config time Message-Id: <20040625103928.3b1b3275.davem@redhat.com> In-Reply-To: <20040625123527.GA11685@gondor.apana.org.au> References: <20040625121147.GA11231@gondor.apana.org.au> <20040625123527.GA11685@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: 6336 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, 25 Jun 2004 22:35:27 +1000 Herbert Xu wrote: > Here is the patch to check encap_type at the earliest possible > opportunity in xfrm_user/af_key. > > This will allow us to assume in esp4 that the encap_type from x->encap > is always valid. Applied. From manfred@colorfullife.com Fri Jun 25 13:32:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 13:32:30 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PKWMgi027869 for ; Fri, 25 Jun 2004 13:32:24 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5PKWHLw025286; Fri, 25 Jun 2004 22:32:18 +0200 Message-ID: <40DC8BC3.2000401@colorfullife.com> Date: Fri, 25 Jun 2004 22:32:03 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik , netdev@oss.sgi.com Subject: [PATCH] natsemi 1: switch to netdev_priv() Content-Type: multipart/mixed; boundary="------------030208040305040608050303" X-archive-position: 6337 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 This is a multi-part message in MIME format. --------------030208040305040608050303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jeff, the attached patch switches natsemi to netdev_priv(). Could you apply it to your tree? The diff is against 2.6.7-mm2. -- Manfred --------------030208040305040608050303 Content-Type: text/plain; name="patch-natsemi-01-priv" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-natsemi-01-priv" --- 2.6/drivers/net/natsemi.c 2004-06-25 21:30:08.454557400 +0200 +++ build-2.6/drivers/net/natsemi.c 2004-06-25 21:35:11.666462184 +0200 @@ -749,7 +749,7 @@ static void move_int_phy(struct net_device *dev, int addr) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int target = 31; /* @@ -840,7 +840,7 @@ dev->base_addr = ioaddr; dev->irq = irq; - np = dev->priv; + np = netdev_priv(dev); np->pci_dev = pdev; pci_set_drvdata(pdev, dev); @@ -1102,7 +1102,7 @@ static int mdio_read(struct net_device *dev, int reg) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The 83815 series has two ports: * - an internal transceiver @@ -1116,7 +1116,7 @@ static void mdio_write(struct net_device *dev, int reg, u16 data) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The 83815 series has an internal transceiver; handle separately */ if (dev->if_port == PORT_TP) @@ -1127,7 +1127,7 @@ static void init_phy_fixup(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int i; u32 cfg; @@ -1239,7 +1239,7 @@ static int switch_port_external(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 cfg; cfg = readl(dev->base_addr + ChipConfig); @@ -1271,7 +1271,7 @@ static int switch_port_internal(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; u32 cfg; u16 bmcr; @@ -1322,7 +1322,7 @@ */ static int find_mii(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int tmp; int i; int did_switch; @@ -1371,7 +1371,7 @@ u32 rfcr; u16 pmatch[3]; u16 sopass[3]; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* * Resetting the chip causes some registers to be lost. @@ -1441,7 +1441,7 @@ static void natsemi_reload_eeprom(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; writel(EepromReload, dev->base_addr + PCIBusCfg); @@ -1462,7 +1462,7 @@ static void natsemi_stop_rxtx(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; writel(RxOff | TxOff, ioaddr + ChipCmd); @@ -1482,7 +1482,7 @@ static int netdev_open(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int i; @@ -1531,7 +1531,7 @@ static void do_cable_magic(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (dev->if_port != PORT_TP) return; @@ -1559,7 +1559,7 @@ * (these values all come from National) */ if (!(data & 0x80) || ((data >= 0xd8) && (data <= 0xff))) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* the bug has been triggered - fix the coefficient */ writew(TSTDAT_FIXED, dev->base_addr + TSTDAT); @@ -1575,7 +1575,7 @@ static void undo_cable_magic(struct net_device *dev) { u16 data; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (dev->if_port != PORT_TP) return; @@ -1593,7 +1593,7 @@ static void check_link(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int duplex; u16 bmsr; @@ -1654,7 +1654,7 @@ static void init_registers(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; init_phy_fixup(dev); @@ -1732,7 +1732,7 @@ static void netdev_timer(unsigned long data) { struct net_device *dev = (struct net_device *)data; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int next_tick = 5*HZ; if (netif_msg_timer(np)) { @@ -1797,7 +1797,7 @@ static void dump_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (netif_msg_pktdata(np)) { int i; @@ -1820,7 +1820,7 @@ static void tx_timeout(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; disable_irq(dev->irq); @@ -1851,7 +1851,7 @@ static int alloc_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); np->rx_ring = pci_alloc_consistent(np->pci_dev, sizeof(struct netdev_desc) * (RX_RING_SIZE+TX_RING_SIZE), &np->ring_dma); @@ -1863,7 +1863,7 @@ static void refill_rx(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* Refill the Rx ring buffers. */ for (; np->cur_rx - np->dirty_rx > 0; np->dirty_rx++) { @@ -1892,7 +1892,7 @@ /* Initialize the Rx and Tx rings, along with various 'dev' bits. */ static void init_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; /* 1) TX ring */ @@ -1931,7 +1931,7 @@ static void drain_tx(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; for (i = 0; i < TX_RING_SIZE; i++) { @@ -1948,7 +1948,7 @@ static void drain_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned int buflen = np->rx_buf_sz + RX_OFFSET; int i; @@ -1969,7 +1969,7 @@ static void free_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); pci_free_consistent(np->pci_dev, sizeof(struct netdev_desc) * (RX_RING_SIZE+TX_RING_SIZE), np->rx_ring, np->ring_dma); @@ -1977,7 +1977,7 @@ static void reinit_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; /* drain TX ring */ @@ -1999,7 +1999,7 @@ static int start_tx(struct sk_buff *skb, struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned entry; /* Note: Ordering is important here, set the field with the @@ -2046,7 +2046,7 @@ static void netdev_tx_done(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); for (; np->cur_tx - np->dirty_tx > 0; np->dirty_tx++) { int entry = np->dirty_tx % TX_RING_SIZE; @@ -2092,7 +2092,7 @@ static irqreturn_t intr_handler(int irq, void *dev_instance, struct pt_regs *rgs) { struct net_device *dev = dev_instance; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; int boguscnt = max_interrupt_work; unsigned int handled = 0; @@ -2150,7 +2150,7 @@ for clarity and better register allocation. */ static void netdev_rx(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int entry = np->cur_rx % RX_RING_SIZE; int boguscnt = np->dirty_rx + RX_RING_SIZE - np->cur_rx; s32 desc_status = le32_to_cpu(np->rx_head_desc->cmd_status); @@ -2241,7 +2241,7 @@ static void netdev_error(struct net_device *dev, int intr_status) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; spin_lock(&np->lock); @@ -2296,7 +2296,7 @@ static void __get_stats(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The chip only need report frame silently dropped. */ np->stats.rx_crc_errors += readl(ioaddr + RxCRCErrs); @@ -2305,7 +2305,7 @@ static struct net_device_stats *get_stats(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* The chip only need report frame silently dropped. */ spin_lock_irq(&np->lock); @@ -2320,7 +2320,7 @@ static void __set_rx_mode(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u8 mc_filter[64]; /* Multicast hash filter */ u32 rx_mode; @@ -2357,7 +2357,7 @@ static void set_rx_mode(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); spin_lock_irq(&np->lock); if (!np->hands_off) __set_rx_mode(dev); @@ -2366,7 +2366,7 @@ static int netdev_ethtool_ioctl(struct net_device *dev, void __user *useraddr) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 cmd; if (get_user(cmd, (u32 __user *)useraddr)) @@ -2537,7 +2537,7 @@ static int netdev_set_wol(struct net_device *dev, u32 newval) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 data = readl(dev->base_addr + WOLCmd) & ~WakeOptsSummary; /* translate to bitmasks this chip understands */ @@ -2566,7 +2566,7 @@ static int netdev_get_wol(struct net_device *dev, u32 *supported, u32 *cur) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 regval = readl(dev->base_addr + WOLCmd); *supported = (WAKE_PHY | WAKE_UCAST | WAKE_MCAST | WAKE_BCAST @@ -2601,7 +2601,7 @@ static int netdev_set_sopass(struct net_device *dev, u8 *newval) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u16 *sval = (u16 *)newval; u32 addr; @@ -2632,7 +2632,7 @@ static int netdev_get_sopass(struct net_device *dev, u8 *data) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u16 *sval = (u16 *)data; u32 addr; @@ -2660,7 +2660,7 @@ static int netdev_get_ecmd(struct net_device *dev, struct ethtool_cmd *ecmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); u32 tmp; ecmd->port = dev->if_port; @@ -2738,7 +2738,7 @@ static int netdev_set_ecmd(struct net_device *dev, struct ethtool_cmd *ecmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (ecmd->port != PORT_TP && ecmd->port != PORT_MII && ecmd->port != PORT_FIBRE) return -EINVAL; @@ -2879,7 +2879,7 @@ static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct mii_ioctl_data *data = if_mii(rq); - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); switch(cmd) { case SIOCETHTOOL: @@ -2938,7 +2938,7 @@ static void enable_wol_mode(struct net_device *dev, int enable_intr) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (netif_msg_wol(np)) printk(KERN_INFO "%s: remaining active for wake-on-lan\n", @@ -2971,7 +2971,7 @@ static int netdev_close(struct net_device *dev) { long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (netif_msg_ifdown(np)) printk(KERN_DEBUG @@ -3083,7 +3083,7 @@ static int natsemi_suspend (struct pci_dev *pdev, u32 state) { struct net_device *dev = pci_get_drvdata (pdev); - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); long ioaddr = dev->base_addr; rtnl_lock(); @@ -3130,7 +3130,7 @@ static int natsemi_resume (struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata (pdev); - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); rtnl_lock(); if (netif_device_present(dev)) --------------030208040305040608050303-- From manfred@colorfullife.com Fri Jun 25 13:54:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 13:54:52 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PKskgi028502 for ; Fri, 25 Jun 2004 13:54:47 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5PKshLw025439; Fri, 25 Jun 2004 22:54:44 +0200 Message-ID: <40DC9105.60901@colorfullife.com> Date: Fri, 25 Jun 2004 22:54:29 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: [PATCH] natsemi 2: support packets > 1518 bytes Content-Type: multipart/mixed; boundary="------------080309080001000203030604" X-archive-position: 6338 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 This is a multi-part message in MIME format. --------------080309080001000203030604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jeff, attached is the promised cleanup of the vlan handling: By default, the DP83815/6 nics reject packets larger than 1518 bytes. This must be disabled by setting the RxAcceptLong flag, otherwise vlan doesn't work. This is now properly implemented. The patch also adds support for larger than normal frames: the nic can support up to 2046 byte frames, i.e. mtu 2024. I've tested mtu 2000 between two natsemi nics: tcp bandwidth up from 11.7 to 11.9 MB/sec. Additionally, it fixes a bug in the tx overrun handling: The drain threshold must be limited to 1472 bytes, larger settings are documented to cause internal nic corruptions. Jeff, could you apply it to your tree and forward it? Signed-Off-By: Manfred Spraul --------------080309080001000203030604 Content-Type: text/plain; name="patch-natsemi-02-long" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-natsemi-02-long" --- 2.6/drivers/net/natsemi.c 2004-06-25 21:35:53.321129712 +0200 +++ build-2.6/drivers/net/natsemi.c 2004-06-25 21:36:11.809319080 +0200 @@ -236,7 +236,14 @@ #define NATSEMI_REGS_SIZE (NATSEMI_NREGS * sizeof(u32)) #define NATSEMI_EEPROM_SIZE 24 /* 12 16-bit values */ -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */ +/* Buffer sizes: + * The nic writes 32-bit values, even if the upper bytes of + * a 32-bit value are beyond the end of the buffer. + */ +#define NATSEMI_HEADERS 22 /* 2*mac,type,vlan,crc */ +#define NATSEMI_PADDING 16 /* 2 bytes should be sufficient */ +#define NATSEMI_LONGPKT 1518 /* limit for normal packets */ +#define NATSEMI_RX_LIMIT 2046 /* maximum supported by hardware */ /* These identify the driver base version and may not be removed. */ static char version[] __devinitdata = @@ -539,6 +546,22 @@ TxCarrierIgn = 0x80000000 }; +/* + * Tx Configuration: + * - 256 byte DMA burst length + * - fill threshold 512 bytes (i.e. restart DMA when 512 bytes are free) + * - 64 bytes initial drain threshold (i.e. begin actual transmission + * when 64 byte are in the fifo) + * - on tx underruns, increase drain threshold by 64. + * - at most use a drain threshold of 1472 bytes: The sum of the fill + * threshold and the drain threshold must be less than 2016 bytes. + * + */ +#define TX_FLTH_VAL ((512/32) << 8) +#define TX_DRTH_VAL_START (64/32) +#define TX_DRTH_VAL_INC 2 +#define TX_DRTH_VAL_LIMIT (1472/32) + enum RxConfig_bits { RxDrthMask = 0x3e, RxMxdmaMask = 0x700000, @@ -555,6 +578,7 @@ RxAcceptRunt = 0x40000000, RxAcceptErr = 0x80000000 }; +#define RX_DRTH_VAL (128/8) enum ClkRun_bits { PMEEnable = 0x100, @@ -731,6 +755,7 @@ static void netdev_error(struct net_device *dev, int intr_status); static void netdev_rx(struct net_device *dev); static void netdev_tx_done(struct net_device *dev); +static int natsemi_change_mtu(struct net_device *dev, int new_mtu); static void __set_rx_mode(struct net_device *dev); static void set_rx_mode(struct net_device *dev); static void __get_stats(struct net_device *dev); @@ -897,6 +922,7 @@ dev->stop = &netdev_close; dev->get_stats = &get_stats; dev->set_multicast_list = &set_rx_mode; + dev->change_mtu = &natsemi_change_mtu; dev->do_ioctl = &netdev_ioctl; dev->tx_timeout = &tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; @@ -1680,15 +1706,16 @@ * ECRETRY=1 * ATP=1 */ - np->tx_config = TxAutoPad | TxCollRetry | TxMxdma_256 | (0x1002); + np->tx_config = TxAutoPad | TxCollRetry | TxMxdma_256 | + TX_FLTH_VAL | TX_DRTH_VAL_START; writel(np->tx_config, ioaddr + TxConfig); /* DRTH 0x10: start copying to memory if 128 bytes are in the fifo * MXDMA 0: up to 256 byte bursts */ - np->rx_config = RxMxdma_256 | 0x20; + np->rx_config = RxMxdma_256 | RX_DRTH_VAL; /* if receive ring now has bigger buffers than normal, enable jumbo */ - if (np->rx_buf_sz > PKT_BUF_SZ) + if (np->rx_buf_sz > NATSEMI_LONGPKT) np->rx_config |= RxAcceptLong; writel(np->rx_config, ioaddr + RxConfig); @@ -1870,7 +1897,7 @@ struct sk_buff *skb; int entry = np->dirty_rx % RX_RING_SIZE; if (np->rx_skbuff[entry] == NULL) { - unsigned int buflen = np->rx_buf_sz + RX_OFFSET; + unsigned int buflen = np->rx_buf_sz+NATSEMI_PADDING; skb = dev_alloc_skb(buflen); np->rx_skbuff[entry] = skb; if (skb == NULL) @@ -1889,6 +1916,15 @@ } } +static void set_bufsize(struct net_device *dev) +{ + struct netdev_private *np = netdev_priv(dev); + if (dev->mtu <= ETH_DATA_LEN) + np->rx_buf_sz = ETH_DATA_LEN + NATSEMI_HEADERS; + else + np->rx_buf_sz = dev->mtu + NATSEMI_HEADERS; +} + /* Initialize the Rx and Tx rings, along with various 'dev' bits. */ static void init_ring(struct net_device *dev) { @@ -1909,9 +1945,8 @@ np->dirty_rx = 0; np->cur_rx = RX_RING_SIZE; np->oom = 0; - np->rx_buf_sz = PKT_BUF_SZ; - if (dev->mtu > ETH_DATA_LEN) - np->rx_buf_sz += dev->mtu - ETH_DATA_LEN; + set_bufsize(dev); + np->rx_head_desc = &np->rx_ring[0]; /* Please be carefull before changing this loop - at least gcc-2.95.1 @@ -1946,10 +1981,10 @@ } } -static void drain_ring(struct net_device *dev) +static void drain_rx(struct net_device *dev) { - struct netdev_private *np = netdev_priv(dev); - unsigned int buflen = np->rx_buf_sz + RX_OFFSET; + struct netdev_private *np = netdev_priv(dev); + unsigned int buflen = np->rx_buf_sz; int i; /* Free all the skbuffs in the Rx queue. */ @@ -1964,6 +1999,11 @@ } np->rx_skbuff[i] = NULL; } +} + +static void drain_ring(struct net_device *dev) +{ + drain_rx(dev); drain_tx(dev); } @@ -1975,17 +2015,11 @@ np->rx_ring, np->ring_dma); } -static void reinit_ring(struct net_device *dev) +static void reinit_rx(struct net_device *dev) { struct netdev_private *np = netdev_priv(dev); int i; - /* drain TX ring */ - drain_tx(dev); - np->dirty_tx = np->cur_tx = 0; - for (i=0;itx_ring[i].cmd_status = 0; - /* RX Ring */ np->dirty_rx = 0; np->cur_rx = RX_RING_SIZE; @@ -1997,6 +2031,20 @@ refill_rx(dev); } +static void reinit_ring(struct net_device *dev) +{ + struct netdev_private *np = netdev_priv(dev); + int i; + + /* drain TX ring */ + drain_tx(dev); + np->dirty_tx = np->cur_tx = 0; + for (i=0;itx_ring[i].cmd_status = 0; + + reinit_rx(dev); +} + static int start_tx(struct sk_buff *skb, struct net_device *dev) { struct netdev_private *np = netdev_priv(dev); @@ -2154,7 +2202,7 @@ int entry = np->cur_rx % RX_RING_SIZE; int boguscnt = np->dirty_rx + RX_RING_SIZE - np->cur_rx; s32 desc_status = le32_to_cpu(np->rx_head_desc->cmd_status); - unsigned int buflen = np->rx_buf_sz + RX_OFFSET; + unsigned int buflen = np->rx_buf_sz; /* If the driver owns the next entry it's a new packet. Send it up. */ while (desc_status < 0) { /* e.g. & DescOwn */ @@ -2263,12 +2311,18 @@ __get_stats(dev); } if (intr_status & IntrTxUnderrun) { - if ((np->tx_config & TxDrthMask) < 62) - np->tx_config += 2; - if (netif_msg_tx_err(np)) - printk(KERN_NOTICE - "%s: increased Tx threshold, txcfg %#08x.\n", - dev->name, np->tx_config); + if ((np->tx_config & TxDrthMask) < TX_DRTH_VAL_LIMIT) { + np->tx_config += TX_DRTH_VAL_INC; + if (netif_msg_tx_err(np)) + printk(KERN_NOTICE + "%s: increased tx threshold, txcfg %#08x.\n", + dev->name, np->tx_config); + } else { + if (netif_msg_tx_err(np)) + printk(KERN_NOTICE + "%s: tx underrun with maximum tx threshold, txcfg %#08x.\n", + dev->name, np->tx_config); + } writel(np->tx_config, ioaddr + TxConfig); } if (intr_status & WOLPkt && netif_msg_wol(np)) { @@ -2355,6 +2409,36 @@ np->cur_rx_mode = rx_mode; } +static int natsemi_change_mtu(struct net_device *dev, int new_mtu) +{ + if (new_mtu < 64 || new_mtu > NATSEMI_RX_LIMIT-NATSEMI_HEADERS) + return -EINVAL; + + dev->mtu = new_mtu; + + /* synchronized against open : rtnl_lock() held by caller */ + if (netif_running(dev)) { + struct netdev_private *np = netdev_priv(dev); + long ioaddr = dev->base_addr; + + disable_irq(dev->irq); + spin_lock(&np->lock); + /* stop engines */ + natsemi_stop_rxtx(dev); + /* drain rx queue */ + drain_rx(dev); + /* change buffers */ + set_bufsize(dev); + reinit_rx(dev); + writel(np->ring_dma, ioaddr + RxRingPtr); + /* restart engines */ + writel(RxOn | TxOn, ioaddr + ChipCmd); + spin_unlock(&np->lock); + enable_irq(dev->irq); + } + return 0; +} + static void set_rx_mode(struct net_device *dev) { struct netdev_private *np = netdev_priv(dev); @@ -2876,6 +2960,7 @@ } return 0; } + static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct mii_ioctl_data *data = if_mii(rq); --------------080309080001000203030604-- From herbert@gondor.apana.org.au Fri Jun 25 14:58:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 14:58:21 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PLwDgi030209 for ; Fri, 25 Jun 2004 14:58: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 1Bdyhk-00050h-00; Sat, 26 Jun 2004 07:57:52 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bdyhf-0003tU-00; Sat, 26 Jun 2004 07:57:47 +1000 Date: Sat, 26 Jun 2004 07:57:47 +1000 To: "David S. Miller" Cc: agruen@suse.de, netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-ID: <20040625215747.GA14930@gondor.apana.org.au> References: <20040624123603.GA1241@gondor.apana.org.au> <20040625101231.6f6b2f12.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625101231.6f6b2f12.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6339 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 Fri, Jun 25, 2004 at 10:12:31AM -0700, David S. Miller wrote: > > I now think it's trying to account for the udpdata32[] header area. > But that's not 2 bytes, it's (2 * sizeof(u32)) or 8 bytes. That's what I thought too, but that is already accounted by x->props.header_len in init_state. In any case, just increasing alen like that is wrong. It needs to do at least three other things: 1. Allocate memory for it in skb_cow_data. 2. Fill in those bytes with data so we don't leak information. 3. Teach get_max_size about it. Andreas, can you please clarify for us as to what those two bytes are 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 davem@redhat.com Fri Jun 25 15:10:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 15:10:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PMA0gi030842 for ; Fri, 25 Jun 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 i5PM9pe1012156; Fri, 25 Jun 2004 18:09:51 -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 i5PM9p017239; Fri, 25 Jun 2004 18:09:51 -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 i5PM9SEI017366; Fri, 25 Jun 2004 18:09:28 -0400 Date: Fri, 25 Jun 2004 15:09:26 -0700 From: "David S. Miller" To: Herbert Xu Cc: agruen@suse.de, netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-Id: <20040625150926.41342f8b.davem@redhat.com> In-Reply-To: <20040625215747.GA14930@gondor.apana.org.au> References: <20040624123603.GA1241@gondor.apana.org.au> <20040625101231.6f6b2f12.davem@redhat.com> <20040625215747.GA14930@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: 6340 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 Sat, 26 Jun 2004 07:57:47 +1000 Herbert Xu wrote: > Andreas, can you please clarify for us as to what those two bytes > are for? Yes, Andrea please do. You've been very quiet and it is possible that you posses the key to unlock this mystery :-) From davem@redhat.com Fri Jun 25 15:12:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 15:12:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PMCYgi031175 for ; Fri, 25 Jun 2004 15:12:35 -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 i5PMCUe1012697; Fri, 25 Jun 2004 18:12: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 i5PMCU017869; Fri, 25 Jun 2004 18:12:30 -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 i5PMC7Wp019272; Fri, 25 Jun 2004 18:12:07 -0400 Date: Fri, 25 Jun 2004 15:12:05 -0700 From: "David S. Miller" To: Andreas Gruenbacher Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-Id: <20040625151205.1d37843e.davem@redhat.com> In-Reply-To: <1088201622.25933.9.camel@winden.suse.de> References: <20040624123603.GA1241@gondor.apana.org.au> <20040625101231.6f6b2f12.davem@redhat.com> <20040625215747.GA14930@gondor.apana.org.au> <1088201622.25933.9.camel@winden.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: 6341 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 Sat, 26 Jun 2004 00:13:42 +0200 Andreas Gruenbacher wrote: > I think I'm not the right person to address this question to .Did you > mean to ask Dave? I'm also missing the context here I'm afraid; is there > an archive of the whole thread somewhere? Andreas, it was your non-IKE encapsulation patch from the SUSE kernel tree that I integrated into the 2.5.x sources long ago. That is why we are asking you, the code came from you :-) From agruen@suse.de Fri Jun 25 15:47:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 15:47:32 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PMlCgi032141 for ; Fri, 25 Jun 2004 15:47: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 60B837C39B0; Sat, 26 Jun 2004 00:09:17 +0200 (CEST) Subject: Re: [NAT-T] NON-IKE encapsulation From: Andreas Gruenbacher To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040625215747.GA14930@gondor.apana.org.au> References: <20040624123603.GA1241@gondor.apana.org.au> <20040625101231.6f6b2f12.davem@redhat.com> <20040625215747.GA14930@gondor.apana.org.au> Content-Type: text/plain Organization: SUSE Labs Message-Id: <1088201622.25933.9.camel@winden.suse.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 26 Jun 2004 00:13:42 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 6342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: netdev Hello, On Fri, 2004-06-25 at 23:57, Herbert Xu wrote: > On Fri, Jun 25, 2004 at 10:12:31AM -0700, David S. Miller wrote: > > > > I now think it's trying to account for the udpdata32[] header area. > > But that's not 2 bytes, it's (2 * sizeof(u32)) or 8 bytes. > > That's what I thought too, but that is already accounted by > x->props.header_len in init_state. > > In any case, just increasing alen like that is wrong. It needs to > do at least three other things: > > 1. Allocate memory for it in skb_cow_data. > 2. Fill in those bytes with data so we don't leak information. > 3. Teach get_max_size about it. > > Andreas, can you please clarify for us as to what those two bytes > are for? I think I'm not the right person to address this question to .Did you mean to ask Dave? I'm also missing the context here I'm afraid; is there an archive of the whole thread somewhere? Cheers, -- Andreas Gruenbacher SUSE Labs, SUSE LINUX AG From agruen@suse.de Fri Jun 25 16:26:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 16:26:17 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5PNQAgi003828 for ; Fri, 25 Jun 2004 16:26: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 7BF327C47D9; Sat, 26 Jun 2004 01:26:04 +0200 (CEST) Subject: Re: [NAT-T] NON-IKE encapsulation From: Andreas Gruenbacher To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040625215747.GA14930@gondor.apana.org.au> References: <20040624123603.GA1241@gondor.apana.org.au> <20040625101231.6f6b2f12.davem@redhat.com> <20040625215747.GA14930@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-U0g4M2Kzyf8oqhVmy+zn" Organization: SUSE Labs Message-Id: <1088206229.25933.57.camel@winden.suse.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 26 Jun 2004 01:30:29 +0200 X-archive-position: 6343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: netdev --=-U0g4M2Kzyf8oqhVmy+zn Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, On Fri, 2004-06-25 at 23:57, Herbert Xu wrote: > On Fri, Jun 25, 2004 at 10:12:31AM -0700, David S. Miller wrote: > > > > I now think it's trying to account for the udpdata32[] header area. > > But that's not 2 bytes, it's (2 * sizeof(u32)) or 8 bytes. > > That's what I thought too, but that is already accounted by > x->props.header_len in init_state. > > In any case, just increasing alen like that is wrong. It needs to > do at least three other things: > > 1. Allocate memory for it in skb_cow_data. > 2. Fill in those bytes with data so we don't leak information. > 3. Teach get_max_size about it. > > Andreas, can you please clarify for us as to what those two bytes > are for? Your analyses are entirely correct. The two instances of ``alen += 2'' are indeed complete nonsense. The extra 8 bytes required are already accounted for in header_len; nothing other than the two zero-filled words is required for this encapsulation mode. Attached is a new version of the original patch, and a relative diff for reference. Thanks for reviewing and for reporting. (And sorry for the confusion; I'm a bit stressed out at the moment.) Cheers, -- Andreas Gruenbacher SUSE Labs, SUSE LINUX AG --=-U0g4M2Kzyf8oqhVmy+zn Content-Disposition: attachment; filename=ipsec-nat-t-old Content-Type: text/plain; name=ipsec-nat-t-old; charset=utf-8 Content-Transfer-Encoding: 7bit This adds support for the old NAT Traversal packet format described in draft-ietf-ipsec-udp-encaps-00/01. More recent Internet Drafts define an improved format, but some ipsec implementations still don't support that. Andreas Gruenbacher , SUSE Labs, 2004. Index: linux-2.6.5/net/ipv4/udp.c =================================================================== --- linux-2.6.5.orig/net/ipv4/udp.c +++ linux-2.6.5/net/ipv4/udp.c @@ -975,6 +975,7 @@ static int udp_encap_rcv(struct sock * s /* Must be an IKE packet.. pass it through */ return 1; + decaps: /* At this point we are sure that this is an ESPinUDP packet, * so we need to remove 'len' bytes from the packet (the UDP * header and optional ESP marker bytes) and then modify the @@ -1002,6 +1003,20 @@ static int udp_encap_rcv(struct sock * s /* and let the caller know to send this into the ESP processor... */ return -1; + case UDP_ENCAP_ESPINUDP_NON_IKE: + /* Check if this is a keepalive packet. If so, eat it. */ + if (len == 1 && udpdata[0] == 0xff) { + return 0; + } else if (len > 2 * sizeof(u32) + sizeof(struct ip_esp_hdr) && + udpdata32[0] == 0 && udpdata32[1] == 0) { + + /* ESP Packet with Non-IKE marker */ + len = sizeof(struct udphdr) + 2 * sizeof(u32); + goto decaps; + } else + /* Must be an IKE packet.. pass it through */ + return 1; + default: if (net_ratelimit()) printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", Index: linux-2.6.5/net/ipv4/esp4.c =================================================================== --- linux-2.6.5.orig/net/ipv4/esp4.c +++ linux-2.6.5/net/ipv4/esp4.c @@ -31,6 +31,7 @@ int esp_output(struct sk_buff *skb) struct esp_data *esp; struct sk_buff *trailer; struct udphdr *uh = NULL; + u32 *udpdata32; struct xfrm_encap_tmpl *encap = NULL; int blksize; int clen; @@ -97,6 +98,13 @@ int esp_output(struct sk_buff *skb) esph = (struct ip_esp_hdr*)(uh+1); top_iph->protocol = IPPROTO_UDP; break; + case UDP_ENCAP_ESPINUDP_NON_IKE: + uh = (struct udphdr*) esph; + udpdata32 = (u32*)(uh+1); + udpdata32[0] = udpdata32[1] = 0; + esph = (struct ip_esp_hdr*)(udpdata32+2); + top_iph->protocol = IPPROTO_UDP; + break; default: printk(KERN_INFO "esp_output(): Unhandled encap: %u\n", @@ -132,6 +140,13 @@ int esp_output(struct sk_buff *skb) esph = (struct ip_esp_hdr*)(uh+1); top_iph->protocol = IPPROTO_UDP; break; + case UDP_ENCAP_ESPINUDP_NON_IKE: + uh = (struct udphdr*) esph; + udpdata32 = (u32*)(uh+1); + udpdata32[0] = udpdata32[1] = 0; + esph = (struct ip_esp_hdr*)(udpdata32+2); + top_iph->protocol = IPPROTO_UDP; + break; default: printk(KERN_INFO "esp_output(): Unhandled encap: %u\n", @@ -294,6 +309,7 @@ int esp_input(struct xfrm_state *x, stru switch (decap->decap_type) { case UDP_ENCAP_ESPINUDP: + case UDP_ENCAP_ESPINUDP_NON_IKE: if ((void*)uh == (void*)esph) { printk(KERN_DEBUG @@ -354,6 +370,7 @@ int esp_post_input(struct xfrm_state *x, switch (encap->encap_type) { case UDP_ENCAP_ESPINUDP: + case UDP_ENCAP_ESPINUDP_NON_IKE: /* * 1) if the NAT-T peer's IP or port changed then * advertize the change to the keying daemon. @@ -534,6 +551,9 @@ int esp_init_state(struct xfrm_state *x, case UDP_ENCAP_ESPINUDP: x->props.header_len += sizeof(struct udphdr); break; + case UDP_ENCAP_ESPINUDP_NON_IKE: + x->props.header_len += sizeof(struct udphdr) + 2 * sizeof(u32); + break; default: printk (KERN_INFO "esp_init_state(): Unhandled encap type: %u\n", Index: linux-2.6.5/include/linux/udp.h =================================================================== --- linux-2.6.5.orig/include/linux/udp.h +++ linux-2.6.5/include/linux/udp.h @@ -31,6 +31,7 @@ struct udphdr { #define UDP_ENCAP 100 /* Set the socket to accept encapsulated packets */ /* UDP encapsulation types */ +#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */ #define UDP_ENCAP_ESPINUDP 2 /* draft-ietf-ipsec-udp-encaps-06 */ #ifdef __KERNEL__ --=-U0g4M2Kzyf8oqhVmy+zn Content-Disposition: attachment; filename=delta.diff Content-Type: text/x-patch; name=delta.diff; charset=utf-8 Content-Transfer-Encoding: 7bit Index: linux-2.6.5/net/ipv4/esp4.c =================================================================== --- linux-2.6.5.orig/net/ipv4/esp4.c +++ linux-2.6.5/net/ipv4/esp4.c @@ -103,7 +103,6 @@ int esp_output(struct sk_buff *skb) udpdata32 = (u32*)(uh+1); udpdata32[0] = udpdata32[1] = 0; esph = (struct ip_esp_hdr*)(udpdata32+2); - alen += 2; top_iph->protocol = IPPROTO_UDP; break; default: @@ -146,7 +145,6 @@ int esp_output(struct sk_buff *skb) udpdata32 = (u32*)(uh+1); udpdata32[0] = udpdata32[1] = 0; esph = (struct ip_esp_hdr*)(udpdata32+2); - alen += 2; top_iph->protocol = IPPROTO_UDP; break; default: --=-U0g4M2Kzyf8oqhVmy+zn-- From herbert@gondor.apana.org.au Fri Jun 25 17:47:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 17:47:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5Q0lPgi005519 for ; Fri, 25 Jun 2004 17:47: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 1Be1Lf-0006NW-00; Sat, 26 Jun 2004 10:47:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Be1Lb-00048d-00; Sat, 26 Jun 2004 10:47:11 +1000 Date: Sat, 26 Jun 2004 10:47:11 +1000 To: Andreas Gruenbacher Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [NAT-T] NON-IKE encapsulation Message-ID: <20040626004711.GA15898@gondor.apana.org.au> References: <20040624123603.GA1241@gondor.apana.org.au> <20040625101231.6f6b2f12.davem@redhat.com> <20040625215747.GA14930@gondor.apana.org.au> <1088206229.25933.57.camel@winden.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1088206229.25933.57.camel@winden.suse.de> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6344 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, Jun 26, 2004 at 01:30:29AM +0200, Andreas Gruenbacher wrote: > > Attached is a new version of the original patch, and a relative diff for > reference. Thanks for reviewing and for reporting. (And sorry for the > confusion; I'm a bit stressed out at the moment.) Thank you for taking the time. Dave, I'll assume that this patch has been applied in my subsequent work that touches esp4.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 herbert@gondor.apana.org.au Fri Jun 25 18:57:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 18:57:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5Q1vPgi007490 for ; Fri, 25 Jun 2004 18:57: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 1Be2RT-0006fa-00; Sat, 26 Jun 2004 11:57:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Be2RP-0004Ik-00; Sat, 26 Jun 2004 11:57:15 +1000 Date: Sat, 26 Jun 2004 11:57:15 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [IPSEC] Remove run-time encap_type checks in esp4 Message-ID: <20040626015715.GA16496@gondor.apana.org.au> References: <20040625121147.GA11231@gondor.apana.org.au> <20040625123527.GA11685@gondor.apana.org.au> <20040625103928.3b1b3275.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20040625103928.3b1b3275.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 6345 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 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 25, 2004 at 10:39:28AM -0700, David S. Miller wrote: > On Fri, 25 Jun 2004 22:35:27 +1000 > Herbert Xu wrote: > > > Here is the patch to check encap_type at the earliest possible > > opportunity in xfrm_user/af_key. > > Applied. Thanks. This allows us to remove all the per-packet checks on x->encap->encap_type. I've left the check in esp_input just in case someone adds a non-ESP encap type in future. However, printing a warning and then continuing is definitely wrong. So expect a follow-up patch to drop the packet when encap_type is unknown in esp_input. 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 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/esp4.c 1.44 vs edited ===== --- 1.44/net/ipv4/esp4.c 2004-06-25 18:38:22 +10:00 +++ edited/net/ipv4/esp4.c 2004-06-26 11:47:15 +10:00 @@ -94,8 +94,9 @@ if (x->props.mode) { top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); esph = (struct ip_esp_hdr*)(top_iph+1); - if (encap && encap->encap_type) { + if (encap) { switch (encap->encap_type) { + default: case UDP_ENCAP_ESPINUDP: uh = (struct udphdr*) esph; esph = (struct ip_esp_hdr*)(uh+1); @@ -108,12 +109,6 @@ esph = (struct ip_esp_hdr*)(udpdata32+2); top_iph->protocol = IPPROTO_UDP; break; - default: - printk(KERN_INFO - "esp_output(): Unhandled encap: %u\n", - encap->encap_type); - top_iph->protocol = IPPROTO_ESP; - break; } } else top_iph->protocol = IPPROTO_ESP; @@ -136,8 +131,9 @@ esph = (struct ip_esp_hdr*)skb_push(*pskb, x->props.header_len); top_iph = (struct iphdr*)skb_push(*pskb, iph->ihl*4); memcpy(top_iph, &tmp_iph, iph->ihl*4); - if (encap && encap->encap_type) { + if (encap) { switch (encap->encap_type) { + default: case UDP_ENCAP_ESPINUDP: uh = (struct udphdr*) esph; esph = (struct ip_esp_hdr*)(uh+1); @@ -150,12 +146,6 @@ esph = (struct ip_esp_hdr*)(udpdata32+2); top_iph->protocol = IPPROTO_UDP; break; - default: - printk(KERN_INFO - "esp_output(): Unhandled encap: %u\n", - encap->encap_type); - top_iph->protocol = IPPROTO_ESP; - break; } } else top_iph->protocol = IPPROTO_ESP; @@ -365,11 +355,8 @@ if (encap->encap_type != decap->decap_type) return -EINVAL; - /* Next, if we don't have an encap type, then ignore it */ - if (!encap->encap_type) - return 0; - switch (encap->encap_type) { + default: case UDP_ENCAP_ESPINUDP: case UDP_ENCAP_ESPINUDP_NON_IKE: /* @@ -406,11 +393,6 @@ skb->ip_summed = CHECKSUM_UNNECESSARY; break; - default: - printk(KERN_INFO - "esp4_post_input(): Unhandled encap type: %u\n", - encap->encap_type); - break; } } return 0; @@ -547,20 +529,14 @@ if (x->encap) { struct xfrm_encap_tmpl *encap = x->encap; - if (encap->encap_type) { - switch (encap->encap_type) { - case UDP_ENCAP_ESPINUDP: - x->props.header_len += sizeof(struct udphdr); - break; - case UDP_ENCAP_ESPINUDP_NON_IKE: - x->props.header_len += sizeof(struct udphdr) + 2 * sizeof(u32); - break; - default: - printk (KERN_INFO - "esp_init_state(): Unhandled encap type: %u\n", - encap->encap_type); - break; - } + switch (encap->encap_type) { + default: + case UDP_ENCAP_ESPINUDP: + x->props.header_len += sizeof(struct udphdr); + break; + case UDP_ENCAP_ESPINUDP_NON_IKE: + x->props.header_len += sizeof(struct udphdr) + 2 * sizeof(u32); + break; } } x->data = esp; --YiEDa0DAkWCtVeE4-- From herbert@gondor.apana.org.au Fri Jun 25 23:44:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Jun 2004 23:44:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5Q6iegi017776 for ; Fri, 25 Jun 2004 23:44: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 1Be6vR-0007U1-00; Sat, 26 Jun 2004 16:44:33 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Be6vL-0006dN-00; Sat, 26 Jun 2004 16:44:27 +1000 Date: Sat, 26 Jun 2004 16:44:27 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [UDP] Move common code out in udp_encap_rcv Message-ID: <20040626064427.GA25395@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6347 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: 2855 Lines: 100 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch simply moves the common code out of the switch statement in udp_encap_rcv(). 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 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/udp.c 1.62 vs edited ===== --- 1.62/net/ipv4/udp.c 2004-06-25 22:12:27 +10:00 +++ edited/net/ipv4/udp.c 2004-06-26 16:18:17 +10:00 @@ -976,34 +976,6 @@ /* Must be an IKE packet.. pass it through */ return 1; - decaps: - /* At this point we are sure that this is an ESPinUDP packet, - * so we need to remove 'len' bytes from the packet (the UDP - * header and optional ESP marker bytes) and then modify the - * protocol to ESP, and then call into the transform receiver. - */ - - /* Now we can update and verify the packet length... */ - iph = skb->nh.iph; - iphlen = iph->ihl << 2; - iph->tot_len = htons(ntohs(iph->tot_len) - len); - if (skb->len < iphlen + len) { - /* packet is too small!?! */ - return 0; - } - - /* pull the data buffer up to the ESP header and set the - * transport header to point to ESP. Keep UDP on the stack - * for later. - */ - skb->h.raw = skb_pull(skb, len); - - /* modify the protocol (it's ESP!) */ - iph->protocol = IPPROTO_ESP; - - /* and let the caller know to send this into the ESP processor... */ - return -1; - case UDP_ENCAP_ESPINUDP_NON_IKE: /* Check if this is a keepalive packet. If so, eat it. */ if (len == 1 && udpdata[0] == 0xff) { @@ -1013,11 +985,37 @@ /* ESP Packet with Non-IKE marker */ len = sizeof(struct udphdr) + 2 * sizeof(u32); - goto decaps; } else /* Must be an IKE packet.. pass it through */ return 1; } + + /* At this point we are sure that this is an ESPinUDP packet, + * so we need to remove 'len' bytes from the packet (the UDP + * header and optional ESP marker bytes) and then modify the + * protocol to ESP, and then call into the transform receiver. + */ + + /* Now we can update and verify the packet length... */ + iph = skb->nh.iph; + iphlen = iph->ihl << 2; + iph->tot_len = htons(ntohs(iph->tot_len) - len); + if (skb->len < iphlen + len) { + /* packet is too small!?! */ + return 0; + } + + /* pull the data buffer up to the ESP header and set the + * transport header to point to ESP. Keep UDP on the stack + * for later. + */ + skb->h.raw = skb_pull(skb, len); + + /* modify the protocol (it's ESP!) */ + iph->protocol = IPPROTO_ESP; + + /* and let the caller know to send this into the ESP processor... */ + return -1; #endif } --2oS5YaxWCcQjTEyO-- From herbert@gondor.apana.org.au Sat Jun 26 03:07:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 03:07:36 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QA7Sgi027666 for ; Sat, 26 Jun 2004 03:07: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 1BeA5h-00088F-00; Sat, 26 Jun 2004 20:07:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BeA5e-0007O2-00; Sat, 26 Jun 2004 20:07:18 +1000 Date: Sat, 26 Jun 2004 20:07:18 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [IPSEC] Drop bogus NAT-T printks in esp_input Message-ID: <20040626100718.GA28367@gondor.apana.org.au> References: <20040625121147.GA11231@gondor.apana.org.au> <20040625123527.GA11685@gondor.apana.org.au> <20040625103928.3b1b3275.davem@redhat.com> <20040626015715.GA16496@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20040626015715.GA16496@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6348 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: 1820 Lines: 64 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jun 26, 2004 at 11:57:15AM +1000, herbert wrote: > > However, printing a warning and then continuing is definitely wrong. > So expect a follow-up patch to drop the packet when encap_type is > unknown in esp_input. Here is the patch to drop the packet if encap_type is unknown. I've also removed the other two bogus printk's as they cannot occur (printing a message is the last thing you want to do even if they did occur :). 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 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/esp4.c 1.45 vs edited ===== --- 1.45/net/ipv4/esp4.c 2004-06-26 15:42:21 +10:00 +++ edited/net/ipv4/esp4.c 2004-06-26 19:57:22 +10:00 @@ -301,28 +301,14 @@ switch (decap->decap_type) { case UDP_ENCAP_ESPINUDP: case UDP_ENCAP_ESPINUDP_NON_IKE: - - if ((void*)uh == (void*)esph) { - printk(KERN_DEBUG - "esp_input(): Got ESP; expecting ESPinUDP\n"); - break; - } - encap_data->proto = AF_INET; encap_data->saddr.a4 = iph->saddr; encap_data->sport = uh->source; encap_len = (void*)esph - (void*)uh; - if (encap_len != sizeof(*uh)) - printk(KERN_DEBUG - "esp_input(): UDP -> ESP: too much room: %d\n", - encap_len); break; default: - printk(KERN_INFO - "esp_input(): processing unknown encap type: %u\n", - decap->decap_type); - break; + goto out; } } --W/nzBZO5zC0uMSeA-- From davem@redhat.com Sat Jun 26 11:36:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 11:36:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QIaogi011734 for ; Sat, 26 Jun 2004 11:36:51 -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 i5QIake1008831; Sat, 26 Jun 2004 14:36: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 i5QIak007757; Sat, 26 Jun 2004 14:36: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 i5QIaMd9026577; Sat, 26 Jun 2004 14:36:23 -0400 Date: Sat, 26 Jun 2004 11:36:03 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Drop bogus NAT-T printks in esp_input Message-Id: <20040626113603.2c928d1d.davem@redhat.com> In-Reply-To: <20040626100718.GA28367@gondor.apana.org.au> References: <20040625121147.GA11231@gondor.apana.org.au> <20040625123527.GA11685@gondor.apana.org.au> <20040625103928.3b1b3275.davem@redhat.com> <20040626015715.GA16496@gondor.apana.org.au> <20040626100718.GA28367@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: 6350 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: 562 Lines: 15 On Sat, 26 Jun 2004 20:07:18 +1000 Herbert Xu wrote: > On Sat, Jun 26, 2004 at 11:57:15AM +1000, herbert wrote: > > > > However, printing a warning and then continuing is definitely wrong. > > So expect a follow-up patch to drop the packet when encap_type is > > unknown in esp_input. > > Here is the patch to drop the packet if encap_type is unknown. > I've also removed the other two bogus printk's as they cannot > occur (printing a message is the last thing you want to do even > if they did occur :). Also applied, thanks. From davem@redhat.com Sat Jun 26 11:36:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 11:36:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QIaGgi011683 for ; Sat, 26 Jun 2004 11:36:16 -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 i5QIa7e1008773; Sat, 26 Jun 2004 14:36:07 -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 i5QIa7007574; Sat, 26 Jun 2004 14:36:07 -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 i5QIZhr3026346; Sat, 26 Jun 2004 14:35:44 -0400 Date: Sat, 26 Jun 2004 11:35:24 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Remove run-time encap_type checks in esp4 Message-Id: <20040626113524.18a20d0f.davem@redhat.com> In-Reply-To: <20040626015715.GA16496@gondor.apana.org.au> References: <20040625121147.GA11231@gondor.apana.org.au> <20040625123527.GA11685@gondor.apana.org.au> <20040625103928.3b1b3275.davem@redhat.com> <20040626015715.GA16496@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: 6349 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: 267 Lines: 8 On Sat, 26 Jun 2004 11:57:15 +1000 Herbert Xu wrote: > This allows us to remove all the per-packet checks on x->encap->encap_type. > I've left the check in esp_input just in case someone adds a non-ESP encap > type in future. Applied. From davem@redhat.com Sat Jun 26 11:40:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 11:40:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QIePgi012358 for ; Sat, 26 Jun 2004 11:40:26 -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 i5QIeLe1009340; Sat, 26 Jun 2004 14:40: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 i5QIeL008132; Sat, 26 Jun 2004 14:40:21 -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 i5QIdv2U027097; Sat, 26 Jun 2004 14:39:58 -0400 Date: Sat, 26 Jun 2004 11:39:38 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [UDP] Move common code out in udp_encap_rcv Message-Id: <20040626113938.34d4d6cc.davem@redhat.com> In-Reply-To: <20040626064427.GA25395@gondor.apana.org.au> References: <20040626064427.GA25395@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: 6351 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: 200 Lines: 7 On Sat, 26 Jun 2004 16:44:27 +1000 Herbert Xu wrote: > This patch simply moves the common code out of the switch statement > in udp_encap_rcv(). Nice cleanup, applied. From chas@cmf.nrl.navy.mil Sat Jun 26 15:46:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 15:46:07 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QMk0gi021629 for ; Sat, 26 Jun 2004 15:46:03 -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 i5QMjn65009470; Sat, 26 Jun 2004 18:45:49 -0400 (EDT) Message-Id: <200406262245.i5QMjn65009470@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: Stephen Hemminger , netdev@oss.sgi.com Subject: [PATCH][ATM]: fix sparse checker warnings X-url: http://www.nrl.navy.mil/CCS/people/chas/index.html X-mailer: nmh 1.0 Date: Sat, 26 Jun 2004 18:45:50 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 6352 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: 3444 Lines: 85 [ATM]: fix sparse checker warnings (from Stephen Hemminger ) diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c - --- a/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 @@ -562,7 +562,7 @@ atmvcc->push = br2684_push; skb_queue_head_init(©); skb_migrate(&atmvcc->sk->sk_receive_queue, ©); - - while ((skb = skb_dequeue(©))) { + while ((skb = skb_dequeue(©)) != NULL) { BRPRIV(skb->dev)->stats.rx_bytes -= skb->len; BRPRIV(skb->dev)->stats.rx_packets--; br2684_push(atmvcc, skb); diff -Nru a/net/atm/clip.c b/net/atm/clip.c - --- a/net/atm/clip.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/clip.c 2004-06-22 14:04:02 -07:00 @@ -503,7 +503,7 @@ skb_queue_head_init(©); skb_migrate(&vcc->sk->sk_receive_queue, ©); /* re-process everything received between connection setup and MKIP */ - - while ((skb = skb_dequeue(©))) + while ((skb = skb_dequeue(©)) != NULL) if (!clip_devs) { atm_return(vcc,skb->truesize); kfree_skb(skb); diff -Nru a/net/atm/common.c b/net/atm/common.c - --- a/net/atm/common.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/common.c 2004-06-22 14:04:02 -07:00 @@ -187,7 +187,7 @@ vcc_remove_socket(sk); /* no more receive */ - - while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue))) { + while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue)) != NULL) { atm_return(vcc,skb->truesize); kfree_skb(skb); } diff -Nru a/net/atm/lec.c b/net/atm/lec.c - --- a/net/atm/lec.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/lec.c 2004-06-22 14:04:02 -07:00 @@ -567,7 +567,7 @@ if (skb_peek(&vcc->sk->sk_receive_queue)) printk("%s lec_atm_close: closing with messages pending\n", dev->name); - - while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue))) { + while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue)) != NULL) { atm_return(vcc, skb->truesize); dev_kfree_skb(skb); } @@ -1940,7 +1940,7 @@ priv->path_switching_delay)) { struct sk_buff *skb; - - while ((skb = skb_dequeue(&entry->tx_wait))) + while ((skb = skb_dequeue(&entry->tx_wait)) != NULL) lec_send(entry->vcc, skb, entry->priv); entry->last_used = jiffies; entry->status = @@ -2337,7 +2337,7 @@ entry->status == ESI_FLUSH_PENDING) { struct sk_buff *skb; - - while ((skb = skb_dequeue(&entry->tx_wait))) + while ((skb = skb_dequeue(&entry->tx_wait)) != NULL) lec_send(entry->vcc, skb, entry->priv); entry->status = ESI_FORWARD_DIRECT; DPRINTK("LEC_ARP: Flushed\n"); diff -Nru a/net/atm/svc.c b/net/atm/svc.c - --- a/net/atm/svc.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/svc.c 2004-06-22 14:04:02 -07:00 @@ -66,7 +66,7 @@ } /* beware - socket is still in use by atmsigd until the last as_indicate has been answered */ - - while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue))) { + while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue)) != NULL) { DPRINTK("LISTEN REL\n"); sigd_enq2(NULL,as_reject,vcc,NULL,NULL,&vcc->qos,0); dev_kfree_skb(skb); ------- End of Forwarded Message From cw@f00f.org Sat Jun 26 15:52:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 15:52:44 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QMqggi022102 for ; Sat, 26 Jun 2004 15:52:42 -0700 Received: from taniwha.stupidest.org (adsl-63-202-172-209.dsl.snfc21.pacbell.net [63.202.172.209]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i5QMqV5t165780; Sat, 26 Jun 2004 18:52:32 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 5A8611141C63; Sat, 26 Jun 2004 15:52:30 -0700 (PDT) Date: Sat, 26 Jun 2004 15:52:30 -0700 From: Chris Wedgwood To: "chas williams (contractor)" Cc: davem@redhat.com, Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: fix sparse checker warnings Message-ID: <20040626225230.GA12698@taniwha.stupidest.org> References: <200406262245.i5QMjn65009470@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406262245.i5QMjn65009470@ginger.cmf.nrl.navy.mil> X-archive-position: 6353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: netdev Content-Length: 754 Lines: 23 On Sat, Jun 26, 2004 at 06:45:50PM -0400, chas williams (contractor) wrote: > diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c > - --- a/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 forwarding mangled the patch > +++ b/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 > @@ -562,7 +562,7 @@ > atmvcc->push = br2684_push; > skb_queue_head_init(©); > skb_migrate(&atmvcc->sk->sk_receive_queue, ©); > - - while ((skb = skb_dequeue(©))) { > + while ((skb = skb_dequeue(©)) != NULL) { I know it's a matter of style, but I really hate the 'assignment in conditional' warning sparse spews out, especially when many people, myself included really do write while ((a = b)) --- the extra parentheses as a compromise to keep gcc quiet. --cw From chas@cmf.nrl.navy.mil Sat Jun 26 16:04:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 16:04:59 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QN4qgi022647 for ; Sat, 26 Jun 2004 16:04:54 -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 i5QN4eQN009653; Sat, 26 Jun 2004 19:04:40 -0400 (EDT) Message-Id: <200406262304.i5QN4eQN009653@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: Chris Wedgwood , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: fix sparse checker warnings In-Reply-To: Message from Chris Wedgwood of "Sat, 26 Jun 2004 15:52:30 PDT." <20040626225230.GA12698@taniwha.stupidest.org> Date: Sat, 26 Jun 2004 19:04:42 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 6354 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: 3571 Lines: 87 In message <20040626225230.GA12698@taniwha.stupidest.org>,Chris Wedgwood writes : >forwarding mangled the patch a bit of brillant work on my part. here it is again but undamaged. [PATCH][ATM]: fix sparse checker warnings (by Stephen Hemminger ) diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c --- a/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 @@ -562,7 +562,7 @@ atmvcc->push = br2684_push; skb_queue_head_init(©); skb_migrate(&atmvcc->sk->sk_receive_queue, ©); - while ((skb = skb_dequeue(©))) { + while ((skb = skb_dequeue(©)) != NULL) { BRPRIV(skb->dev)->stats.rx_bytes -= skb->len; BRPRIV(skb->dev)->stats.rx_packets--; br2684_push(atmvcc, skb); diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/clip.c 2004-06-22 14:04:02 -07:00 @@ -503,7 +503,7 @@ skb_queue_head_init(©); skb_migrate(&vcc->sk->sk_receive_queue, ©); /* re-process everything received between connection setup and MKIP */ - while ((skb = skb_dequeue(©))) + while ((skb = skb_dequeue(©)) != NULL) if (!clip_devs) { atm_return(vcc,skb->truesize); kfree_skb(skb); diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/common.c 2004-06-22 14:04:02 -07:00 @@ -187,7 +187,7 @@ vcc_remove_socket(sk); /* no more receive */ - while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue))) { + while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue)) != NULL) { atm_return(vcc,skb->truesize); kfree_skb(skb); } diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/lec.c 2004-06-22 14:04:02 -07:00 @@ -567,7 +567,7 @@ if (skb_peek(&vcc->sk->sk_receive_queue)) printk("%s lec_atm_close: closing with messages pending\n", dev->name); - while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue))) { + while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue)) != NULL) { atm_return(vcc, skb->truesize); dev_kfree_skb(skb); } @@ -1940,7 +1940,7 @@ priv->path_switching_delay)) { struct sk_buff *skb; - while ((skb = skb_dequeue(&entry->tx_wait))) + while ((skb = skb_dequeue(&entry->tx_wait)) != NULL) lec_send(entry->vcc, skb, entry->priv); entry->last_used = jiffies; entry->status = @@ -2337,7 +2337,7 @@ entry->status == ESI_FLUSH_PENDING) { struct sk_buff *skb; - while ((skb = skb_dequeue(&entry->tx_wait))) + while ((skb = skb_dequeue(&entry->tx_wait)) != NULL) lec_send(entry->vcc, skb, entry->priv); entry->status = ESI_FORWARD_DIRECT; DPRINTK("LEC_ARP: Flushed\n"); diff -Nru a/net/atm/svc.c b/net/atm/svc.c --- a/net/atm/svc.c 2004-06-22 14:04:02 -07:00 +++ b/net/atm/svc.c 2004-06-22 14:04:02 -07:00 @@ -66,7 +66,7 @@ } /* beware - socket is still in use by atmsigd until the last as_indicate has been answered */ - while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue))) { + while ((skb = skb_dequeue(&vcc->sk->sk_receive_queue)) != NULL) { DPRINTK("LISTEN REL\n"); sigd_enq2(NULL,as_reject,vcc,NULL,NULL,&vcc->qos,0); dev_kfree_skb(skb); From davem@redhat.com Sat Jun 26 16:27:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 16:27:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QNRcgi026622 for ; Sat, 26 Jun 2004 16:27:38 -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 i5QNRTe1023922; Sat, 26 Jun 2004 19:27:29 -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 i5QNRT029679; Sat, 26 Jun 2004 19:27: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 i5QNR5j5012971; Sat, 26 Jun 2004 19:27:05 -0400 Date: Sat, 26 Jun 2004 16:26:41 -0700 From: "David S. Miller" To: Chris Wedgwood Cc: chas@cmf.nrl.navy.mil, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: fix sparse checker warnings Message-Id: <20040626162641.00786ed6.davem@redhat.com> In-Reply-To: <20040626225230.GA12698@taniwha.stupidest.org> References: <200406262245.i5QMjn65009470@ginger.cmf.nrl.navy.mil> <20040626225230.GA12698@taniwha.stupidest.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: 6355 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: 727 Lines: 19 On Sat, 26 Jun 2004 15:52:30 -0700 Chris Wedgwood wrote: > > +++ b/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 > > @@ -562,7 +562,7 @@ > > atmvcc->push = br2684_push; > > skb_queue_head_init(©); > > skb_migrate(&atmvcc->sk->sk_receive_queue, ©); > > > - - while ((skb = skb_dequeue(©))) { > > + while ((skb = skb_dequeue(©)) != NULL) { > > I know it's a matter of style, but I really hate the 'assignment in > conditional' warning sparse spews out, especially when many people, > myself included really do write while ((a = b)) --- the extra > parentheses as a compromise to keep gcc quiet. I think warning for the ((a=b)) case is annoying but not annoying enough to fight against it :) From davem@redhat.com Sat Jun 26 16:28:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 16:28:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QNSbgi026804 for ; Sat, 26 Jun 2004 16:28:37 -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 i5QNSUe1024059; Sat, 26 Jun 2004 19:28: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 i5QNSU029814; Sat, 26 Jun 2004 19:28:30 -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 i5QNS6YH012992; Sat, 26 Jun 2004 19:28:07 -0400 Date: Sat, 26 Jun 2004 16:27:43 -0700 From: "David S. Miller" To: "chas williams (contractor)" Cc: cw@f00f.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: fix sparse checker warnings Message-Id: <20040626162743.7748901c.davem@redhat.com> In-Reply-To: <200406262304.i5QN4eQN009653@ginger.cmf.nrl.navy.mil> References: <20040626225230.GA12698@taniwha.stupidest.org> <200406262304.i5QN4eQN009653@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: 6356 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: 397 Lines: 12 On Sat, 26 Jun 2004 19:04:42 -0400 "chas williams (contractor)" wrote: > In message <20040626225230.GA12698@taniwha.stupidest.org>,Chris Wedgwood writes > : > >forwarding mangled the patch > > a bit of brillant work on my part. here it is again but undamaged. > > [PATCH][ATM]: fix sparse checker warnings (by Stephen Hemminger ) Applied, thanks. From cw@f00f.org Sat Jun 26 16:42:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 16:42:32 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5QNgTgi027596 for ; Sat, 26 Jun 2004 16:42:30 -0700 Received: from taniwha.stupidest.org (adsl-63-202-172-209.dsl.snfc21.pacbell.net [63.202.172.209]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i5QNgL5t064876; Sat, 26 Jun 2004 19:42:22 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 3499A1141C63; Sat, 26 Jun 2004 16:42:21 -0700 (PDT) Date: Sat, 26 Jun 2004 16:42:21 -0700 From: Chris Wedgwood To: "David S. Miller" Cc: chas@cmf.nrl.navy.mil, shemminger@osdl.org, netdev@oss.sgi.com, Linus Torvalds Subject: CodingStyle: while ((a=b)) Message-ID: <20040626234221.GB12761@taniwha.stupidest.org> References: <200406262245.i5QMjn65009470@ginger.cmf.nrl.navy.mil> <20040626225230.GA12698@taniwha.stupidest.org> <20040626162641.00786ed6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040626162641.00786ed6.davem@redhat.com> X-archive-position: 6357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: netdev Content-Length: 451 Lines: 17 On Sat, Jun 26, 2004 at 04:26:41PM -0700, David S. Miller wrote: > I think warning for the ((a=b)) case is annoying but not annoying > enough to fight against it :) Whatever the case, even if I don't like it I would rather see it consistent. Maybe Linus can comment as to whether or not we officially (Documentation/CodingStyle update) want to change things like: while ((a=b)) to while ((a=b) != 0) and similar throughout the code? --cw From bunk@fs.tum.de Sat Jun 26 17:02:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 17:02:32 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5R02Rgi028350 for ; Sat, 26 Jun 2004 17:02:28 -0700 Received: (qmail 17379 invoked from network); 26 Jun 2004 23:57:45 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 26 Jun 2004 23:57:45 -0000 Date: Sun, 27 Jun 2004 02:02:23 +0200 From: Adrian Bunk To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [2.6 patch] remove a superfluous #ifndef from net/ip.h Message-ID: <20040627000222.GQ18303@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 6358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 493 Lines: 23 The patch below removes a superfluous #ifndef from net/ip.h (snmp.h is guarded by the same #ifndef). Signed-off-by: Adrian Bunk Please apply Adrian --- linux-2.6.7-mm2-full/include/net/ip.h.old 2004-06-26 16:28:13.000000000 +0200 +++ linux-2.6.7-mm2-full/include/net/ip.h 2004-06-26 16:28:24.000000000 +0200 @@ -32,10 +32,7 @@ #include #include #include - -#ifndef _SNMP_H #include -#endif struct sock; From chas@cmf.nrl.navy.mil Sat Jun 26 18:20:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 18:20:34 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5R1KUgi030780 for ; Sat, 26 Jun 2004 18:20:30 -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 i5R1KJiN010390; Sat, 26 Jun 2004 21:20:19 -0400 (EDT) Message-Id: <200406270120.i5R1KJiN010390@ginger.cmf.nrl.navy.mil> To: Chris Wedgwood cc: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com, Linus Torvalds Subject: Re: CodingStyle: while ((a=b)) In-Reply-To: Message from Chris Wedgwood of "Sat, 26 Jun 2004 16:42:21 PDT." <20040626234221.GB12761@taniwha.stupidest.org> Date: Sat, 26 Jun 2004 21:20:20 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 6359 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: 455 Lines: 16 In message <20040626234221.GB12761@taniwha.stupidest.org>,Chris Wedgwood writes : > while ((a=b)) to while ((a=b) != 0) adding the != does not make the conditional clearer to me. in fact it just make it harder to read. however, it probably not a good idea to do assignments in places where someone might not expect to see them. the alternative something like this: while (1) { a = b; if (a == 0) break; } but its not very pretty either. From cw@f00f.org Sat Jun 26 18:25:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 18:25:22 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5R1PJgi031181 for ; Sat, 26 Jun 2004 18:25:20 -0700 Received: from taniwha.stupidest.org (adsl-63-202-172-209.dsl.snfc21.pacbell.net [63.202.172.209]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i5R1P55t196942; Sat, 26 Jun 2004 21:25:09 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id D4A6F115C858; Sat, 26 Jun 2004 18:25:04 -0700 (PDT) Date: Sat, 26 Jun 2004 18:25:04 -0700 From: Chris Wedgwood To: "chas williams (contractor)" Cc: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com, Linus Torvalds Subject: Re: CodingStyle: while ((a=b)) Message-ID: <20040627012504.GB14444@taniwha.stupidest.org> References: <20040626234221.GB12761@taniwha.stupidest.org> <200406270120.i5R1KJiN010390@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406270120.i5R1KJiN010390@ginger.cmf.nrl.navy.mil> X-archive-position: 6360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: netdev Content-Length: 723 Lines: 25 On Sat, Jun 26, 2004 at 09:20:20PM -0400, chas williams (contractor) wrote: > adding the != does not make the conditional clearer to me. in fact > it just make it harder to read. so how about we stop merging these particular 'sparse cleanups' until there is a consensus on how things should be done? I'm no saying everyone should agree with me (even though you should) just that consistency is good. > however, it probably not a good idea to do assignments in places > where someone might not expect to see them. I'm not sure this has ever been a problem in the past has it? Consider something like: while(*a++ = *b++); I don't see how that's vague or ugly, and rewriting is just making it worse IMO. --cw From chas@cmf.nrl.navy.mil Sat Jun 26 21:07:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Jun 2004 21:07:19 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5R47Fgi006210 for ; Sat, 26 Jun 2004 21:07:15 -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 i5R4763K011324; Sun, 27 Jun 2004 00:07:06 -0400 (EDT) Message-Id: <200406270407.i5R4763K011324@ginger.cmf.nrl.navy.mil> To: Chris Wedgwood cc: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com, Linus Torvalds Reply-To: chas3@users.sourceforge.net Subject: Re: CodingStyle: while ((a=b)) In-reply-to: Your message of "Sat, 26 Jun 2004 18:25:04 PDT." <20040627012504.GB14444@taniwha.stupidest.org> Date: Sun, 27 Jun 2004 00:07:08 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 6362 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: 363 Lines: 15 In message <20040627012504.GB14444@taniwha.stupidest.org>,Chris Wedgwood writes: >I'm not sure this has ever been a problem in the past has it? as a counter example, tired eyes (and the compiler!) cant tell the difference between: while ((a = b)) if ((a = b)) and while ((a == b)) if ((a == b)) so i just tend to shy away from assignments in conditions. From manfred@colorfullife.com Sun Jun 27 10:13:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Jun 2004 10:14:03 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5RHDrgi012149 for ; Sun, 27 Jun 2004 10:13:54 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5RHDXLw030955; Sun, 27 Jun 2004 19:13:34 +0200 Message-ID: <40DF002C.5070906@colorfullife.com> Date: Sun, 27 Jun 2004 19:13:16 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: Carl-Daniel Hailfinger Subject: [PATCH] further forcedeth updates Content-Type: multipart/mixed; boundary="------------030806080005070503080609" X-archive-position: 6364 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: 47739 Lines: 1444 This is a multi-part message in MIME format. --------------030806080005070503080609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Just a status update on forcedeth: I've moved the phy reset code from nv_open into the probe function and this fixed the msleep(500) under spin_lock_irq() bug. Cable detection now works: to/from gige, etc. vlan and oversized packets work, x86-64 works, bad crc packets are rejected, mii read and write works without the udelay(50). BUT: under load the tx engine crashes and under some circumstances I get lots of tx errors. After a tx crash I must power down the computer to recover. I'm still working on this bug, so don't merge it yet. But please test it - I now have a 250 Gb board, but I can't test the codepaths that are only used for the 100 MBit nic. -- Manfred --------------030806080005070503080609 Content-Type: text/plain; name="candidate-3.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="candidate-3.txt" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 7 // EXTRAVERSION = -mm2 --- 2.6/drivers/net/forcedeth.c 2004-06-27 19:07:56.591450416 +0200 +++ build-2.6/drivers/net/forcedeth.c 2004-06-27 19:07:37.298383408 +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,18 @@ * 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 * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -80,7 +86,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.25" +#define FORCEDETH_VERSION "0.28" #define DRV_NAME "forcedeth" #include @@ -124,6 +130,7 @@ enum { #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 @@ -133,7 +140,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 @@ -160,7 +167,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, @@ -169,6 +176,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 @@ -182,6 +191,9 @@ enum { NvRegMulticastMaskA = 0xB8, NvRegMulticastMaskB = 0xBC, + NvRegPhyInterface = 0xC0, +#define PHY_RGMII 0x10000000 + NvRegTxRingPhysAddr = 0x100, NvRegRxRingPhysAddr = 0x104, NvRegRingSizes = 0x108, @@ -190,12 +202,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 @@ -214,15 +226,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, @@ -254,34 +266,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 @@ -310,10 +351,10 @@ struct ring_desc { #define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ #define RX_RING 128 -#define TX_RING 16 +#define TX_RING 64 /* limited to 1 packet until we understand NV_TX_LASTPACKET */ -#define TX_LIMIT_STOP 10 -#define TX_LIMIT_START 5 +#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) @@ -323,12 +364,46 @@ struct ring_desc { #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) +#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. @@ -346,12 +421,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); @@ -371,7 +449,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; }; /* @@ -396,6 +474,37 @@ static inline void pci_push(u8 * base) readl(base); } +static inline u32 nv_descr_getflags(struct ring_desc *prd, u32 v) +{ + return le32_to_cpu(prd->FlagLen) + & ((v == DESC_VER_1) ? FLAG_MASK_V1 : FLAG_MASK_V2); +} + +static inline void nv_descr_setflags(struct ring_desc *prd, u32 v, u32 flags) +{ + prd->FlagLen = (prd->FlagLen + & cpu_to_le32((v == DESC_VER_1) ? LEN_MASK_V1 : LEN_MASK_V2)) + | cpu_to_le32(flags); +} + +static inline void nv_descr_clearflags(struct ring_desc *prd, u32 v) +{ + prd->FlagLen &= cpu_to_le32((v == DESC_VER_1) ? LEN_MASK_V1 : LEN_MASK_V2); +} + +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 inline void nv_descr_setlength(struct ring_desc *prd, u32 v, u32 length) +{ + prd->FlagLen = (prd->FlagLen + & cpu_to_le32((v == DESC_VER_1) ? FLAG_MASK_V1 : FLAG_MASK_V2)) + | cpu_to_le32(length); +} + static int reg_delay(struct net_device *dev, int offset, u32 mask, u32 target, int delay, int delaymax, const char *msg) { @@ -422,24 +531,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; @@ -461,19 +564,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 */ + msleep(500); + + /* must wait till reset is deasserted */ + while (miicontrol & BMCR_RESET) { + msleep(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); @@ -488,6 +689,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); } @@ -498,8 +701,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); @@ -521,8 +724,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); @@ -530,13 +733,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); } @@ -651,11 +855,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); @@ -670,10 +875,10 @@ 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); + nv_descr_setlength(&np->rx_ring[nr], np->desc_ver, 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", + nv_descr_setflags(&np->rx_ring[nr], np->desc_ver, NV_RX_AVAIL); + dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", dev->name, refill_rx); refill_rx++; } @@ -704,15 +909,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++) + nv_descr_clearflags(&np->tx_ring[i], np->desc_ver); 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++) + nv_descr_clearflags(&np->rx_ring[i], np->desc_ver); return nv_alloc_rx(dev); } @@ -721,7 +924,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; + nv_descr_clearflags(&np->tx_ring[i], np->desc_ver); if (np->tx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->tx_dma[i], np->tx_skbuff[i]->len, @@ -738,7 +941,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; + nv_descr_clearflags(&np->rx_ring[i], np->desc_ver); wmb(); if (np->rx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->rx_dma[i], @@ -770,11 +973,11 @@ 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); + nv_descr_setlength(&np->tx_ring[nr], np->desc_ver, skb->len-1); spin_lock_irq(&np->lock); wmb(); - np->tx_ring[nr].Flags = np->tx_flags; + nv_descr_setflags(&np->tx_ring[nr], np->desc_ver, np->tx_flags); dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n", dev->name, np->next_tx); { @@ -793,7 +996,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; } @@ -806,27 +1009,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 = nv_descr_getflags(&np->tx_ring[i], np->desc_ver); 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, @@ -876,9 +1094,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; @@ -886,11 +1104,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 = nv_descr_getflags(&np->rx_ring[i], np->desc_ver); + 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, */ /* @@ -904,7 +1124,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); @@ -913,41 +1133,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]; @@ -1036,6 +1284,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); } @@ -1043,16 +1293,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) { @@ -1069,47 +1365,75 @@ 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; + +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 &= ~(0x3); + 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); + + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), + base + NvRegMisc1); + pci_push(base); + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); + + return retval; } 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; miistat = readl(base + NvRegMIIStatus); writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); - - miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); - if (miival & BMSR_ANEGCOMPLETE) { - nv_update_linkspeed(dev); + dprintk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); - if (netif_carrier_ok(dev)) { - nv_stop_rx(dev); + 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 { - 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)) { - netif_carrier_off(dev); - printk(KERN_INFO "%s: link down.\n", dev->name); - nv_stop_rx(dev); + if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + printk(KERN_INFO "%s: link down.\n", dev->name); + nv_stop_rx(dev); + } } - writel(np->linkspeed, base + NvRegLinkSpeed); - pci_push(base); } + 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) @@ -1136,7 +1460,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); @@ -1158,7 +1482,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 */ @@ -1211,21 +1535,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); @@ -1233,53 +1563,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); @@ -1291,17 +1599,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); @@ -1309,13 +1612,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); @@ -1324,6 +1623,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); @@ -1332,18 +1632,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; @@ -1448,6 +1757,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) @@ -1507,9 +1824,15 @@ 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) @@ -1517,6 +1840,42 @@ static int __devinit nv_probe(struct pci if (id->driver_data & DEV_NEED_TIMERIRQ) np->irqmask |= NVREG_IRQ_TIMER; + /* 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) { printk(KERN_INFO "forcedeth: unable to register netdev: %d\n", err); @@ -1570,21 +1929,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, }, { /* 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, + }, + { /* 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, }, { /* nForce3 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x00D6, + .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 = 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, @@ -1613,7 +2028,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.6/include/linux/pci_ids.h 2004-06-27 19:07:56.609447680 +0200 +++ build-2.6/include/linux/pci_ids.h 2004-06-27 17:35:20.000000000 +0200 @@ -1063,21 +1063,33 @@ #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_MCP3_AUDIO 0x00da #define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3_IDE 0x00d5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_3 0x00d6 +#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 @@ -1105,6 +1117,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 --------------030806080005070503080609-- From hch@lst.de Sun Jun 27 10:15:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Jun 2004 10:15:58 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5RHFsgi012420 for ; Sun, 27 Jun 2004 10:15:55 -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 i5RHFqQc002849 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 27 Jun 2004 19:15:52 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i5RHFqAs002847; Sun, 27 Jun 2004 19:15:52 +0200 Date: Sun, 27 Jun 2004 19:15:52 +0200 From: Christoph Hellwig To: davem@redhat.com, netdev@oss.sgi.com Subject: Re: old NLMSG_OK fix Message-ID: <20040627171552.GA2797@lst.de> References: <20040531160427.GA19581@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040531160427.GA19581@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6365 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: 1657 Lines: 35 On Mon, May 31, 2004 at 06:04:27PM +0200, Christoph Hellwig wrote: > I just stumbled over NLMSG_OK and RTA_OK changes in the debian kernel > package. It seems they are from > http://oss.sgi.com/projects/netdev/archive/2000-09/msg00001.html > > Any comments? ping --- kernel-source-2.6.6/include/linux/netlink.h 2004-05-10 19:48:07.000000000 +1000 +++ kernel-source-2.6.6-1/include/linux/netlink.h 2004-05-10 22:21:52.000000000 +1000 @@ -73,7 +73,8 @@ #define NLMSG_DATA(nlh) ((void*)(((char*)nlh) + NLMSG_LENGTH(0))) #define NLMSG_NEXT(nlh,len) ((len) -= NLMSG_ALIGN((nlh)->nlmsg_len), \ (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len))) -#define NLMSG_OK(nlh,len) ((len) > 0 && (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \ +#define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \ + (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len <= (len)) #define NLMSG_PAYLOAD(nlh,len) ((nlh)->nlmsg_len - NLMSG_SPACE((len))) --- kernel-source-2.6.6/include/linux/rtnetlink.h 2004-05-10 19:48:08.000000000 +1000 +++ kernel-source-2.6.6-1/include/linux/rtnetlink.h 2004-05-10 22:21:52.000000000 +1000 @@ -69,7 +69,8 @@ #define RTA_ALIGNTO 4 #define RTA_ALIGN(len) ( ((len)+RTA_ALIGNTO-1) & ~(RTA_ALIGNTO-1) ) -#define RTA_OK(rta,len) ((len) > 0 && (rta)->rta_len >= sizeof(struct rtattr) && \ +#define RTA_OK(rta,len) ((len) >= (int)sizeof(struct rtattr) && \ + (rta)->rta_len >= sizeof(struct rtattr) && \ (rta)->rta_len <= (len)) #define RTA_NEXT(rta,attrlen) ((attrlen) -= RTA_ALIGN((rta)->rta_len), \ (struct rtattr*)(((char*)(rta)) + RTA_ALIGN((rta)->rta_len))) From rmk+netdev=oss.sgi.com@arm.linux.org.uk Sun Jun 27 17:02:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Jun 2004 17:02:15 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S029gi031607 for ; Sun, 27 Jun 2004 17:02:11 -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.33) id 1Bejb0-0000M7-4N; Mon, 28 Jun 2004 01:02:02 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.33) id 1Bejaz-00040S-58; Mon, 28 Jun 2004 01:02:01 +0100 Date: Mon, 28 Jun 2004 01:02:01 +0100 From: Russell King To: Linux Kernel List , netdev@oss.sgi.com Subject: Fwd: 2.6.6: IPv6 initialisation bug Message-ID: <20040628010200.A15067@flint.arm.linux.org.uk> Mail-Followup-To: Linux Kernel List , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 6369 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: 4132 Lines: 97 Ok, I've just tried 2.6.7 out on my root-NFS'd firewall with IPv6 built in, and it doesn't work because of the problem I described below. Unfortunately, it's impossible to add the missing "local" routes using /sbin/ip: ip add route local fe80::a00:2bff:fe95:1d7b via :: dev eth0 results in an "unreachable" route being added for that address rather than a local route. What's the solution? Is there a good reason why IPv6 uses the loopback device for local routes? (I'm copying lkml this time since afaik netdev ignored the previous message.) ----- Forwarded message from Russell King ----- Date: Tue, 18 May 2004 16:46:44 +0100 From: Russell King To: netdev@oss.sgi.com Subject: 2.6.6: IPv6 initialisation bug Hi, I think I've found an IPv6 initialisation bug which occurs when IPv6 is modular, and you insert this module when eth0 is up and running, but lo may be down. IPv6 appears to create routes for addresses which are defined as "local" (eg, link local, addresses assigned to the host etc) using the loopback device. However, if the ipv6 module is loaded when lo is down and some other interface is up (eg, in the case of a root-NFS box), then things fall apart. bash-2.04# ip -6 addr 1: eth0: mtu 1500 qlen 1000 inet6 fec0::1:a00:2bff:fe00:193/64 scope site dynamic valid_lft 2591630sec preferred_lft 604430sec inet6 2002:xxxx:xxxx:xxxx:a00:2bff:fe00:193/64 scope global dynamic valid_lft 2591630sec preferred_lft 604430sec inet6 fe80::a00:2bff:fe00:193/64 scope link valid_lft forever preferred_lft forever 2: lo: mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever bash-2.04# ip -6 route show table all local ::1 via :: dev lo proto none metric 0 mtu 16436 advmss 16376 unreachable ::/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable 2002:a00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable 2002:7f00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable 2002:a9fe::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable 2002:ac10::/28 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable 2002:c0a8::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 2002:xxxx:xxxx:xxxx::/64 dev eth0 proto kernel metric 256 expires 2591712sec mtu 1500 advmss 1440 unreachable 2002:e000::/19 dev lo metric 1024 error -101 mtu 16436 advmss 16376 unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 fec0:0:0:1::/64 dev eth0 proto kernel metric 256 expires 2591712sec mtu 1500 advmss 1440 ff02::1 via ff02::1 dev eth0 metric 0 cache mtu 1500 advmss 1440 ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 unreachable default dev lo proto none metric -1 error -101 As you can see, we're missing the local routes for all our addresses against "eth0" - because we tried to add them to the IPv6 routing table when "lo" was down. The result is rather distasteful on the network - we start hammering the local segment with neighbour solicitations for our link local and global addresses, as well as sending neighbour solicitations for other nodes addresses. We receive neighbour advertisment replies, but because we believe we don't own our own address, we forward them back out the same interface triggering yet more neighbour solicitations for our own addresses. So... what's the solution for nodes running off root-NFS where "lo" will always be brought up _after_ some other interface? -- 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 ----- End forwarded message ----- -- 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 davem@redhat.com Sun Jun 27 20:41:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Jun 2004 20:41:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S3fTgi023182 for ; Sun, 27 Jun 2004 20:41:30 -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 i5S3eRe1026581; Sun, 27 Jun 2004 23:40: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 i5S3eR025757; Sun, 27 Jun 2004 23:40:27 -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 i5S3e2Dt029517; Sun, 27 Jun 2004 23:40:03 -0400 Date: Sun, 27 Jun 2004 20:39:15 -0700 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] remove a superfluous #ifndef from net/ip.h Message-Id: <20040627203915.65b56752.davem@redhat.com> In-Reply-To: <20040627000222.GQ18303@fs.tum.de> References: <20040627000222.GQ18303@fs.tum.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: 6371 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: 264 Lines: 11 On Sun, 27 Jun 2004 02:02:23 +0200 Adrian Bunk wrote: > The patch below removes a superfluous #ifndef from net/ip.h (snmp.h is > guarded by the same #ifndef). > > Signed-off-by: Adrian Bunk Looks good to me, applied. Thanks. From davem@redhat.com Sun Jun 27 20:52:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Jun 2004 20:52:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S3qmgi023710 for ; Sun, 27 Jun 2004 20:52:49 -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 i5S3qje1028838; Sun, 27 Jun 2004 23:52:45 -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 i5S3qj027955; Sun, 27 Jun 2004 23:52:45 -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 i5S3qLWc031993; Sun, 27 Jun 2004 23:52:21 -0400 Date: Sun, 27 Jun 2004 20:51:33 -0700 From: "David S. Miller" To: Christoph Hellwig Cc: netdev@oss.sgi.com Subject: Re: old NLMSG_OK fix Message-Id: <20040627205133.11d37f0c.davem@redhat.com> In-Reply-To: <20040627171552.GA2797@lst.de> References: <20040531160427.GA19581@lst.de> <20040627171552.GA2797@lst.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: 6372 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: 451 Lines: 13 On Sun, 27 Jun 2004 19:15:52 +0200 Christoph Hellwig wrote: > http://oss.sgi.com/projects/netdev/archive/2000-09/msg00001.html It works because there is always 16 bytes of scratch at the end of an SKB more than was allocated for the actual data. So blindly deref'ing the nlmsg_len value is fine here. There is no danger for OOPS's or kernel corruption. I believe I responded exactly like this the last time this patch was presented. From wli@holomorphy.com Mon Jun 28 01:08:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 01:08:11 -0700 (PDT) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S884gi002224 for ; Mon, 28 Jun 2004 01:08:05 -0700 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1BerBJ-00073f-00; Mon, 28 Jun 2004 01:08:01 -0700 Date: Mon, 28 Jun 2004 01:08:01 -0700 From: William Lee Irwin III To: linux-kernel@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, akpm@osdl.org, davem@redhat.com Subject: kiocb->private is too large for kiocb's on-stack Message-ID: <20040628080801.GO21066@holomorphy.com> Mail-Followup-To: William Lee Irwin III , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, akpm@osdl.org, davem@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 6374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: netdev Content-Length: 5824 Lines: 198 sizeof(struct kiocb) is dangerously large for a structure commonly allocated on-stack. This patch converts the 24*sizeof(long) field, ->private, to a void pointer for use by file_operations entrypoints. A ->dtor() method is added to the kiocb in order to support the release of dynamically allocated structures referred to by ->private. The sole in-tree users of ->private are async network read/write, which are not, in fact, async, and so need not handle preallocated ->private as they would need to if ->ki_retry were ever used. The sole truly async operations are direct IO pread()/pwrite() which do not now use ->ki_retry(). All they would need to do in that case is to check for ->private already being allocated for async kiocbs. This rips 88B off the stack on 32-bit in the common case. vs. 2.6.7-mm3 Index: mm3-2.6.7/include/net/sock.h =================================================================== --- mm3-2.6.7.orig/include/net/sock.h 2004-06-27 15:44:42.365168400 -0700 +++ mm3-2.6.7/include/net/sock.h 2004-06-27 15:50:40.651700568 -0700 @@ -617,17 +617,17 @@ struct scm_cookie *scm; struct msghdr *msg, async_msg; struct iovec async_iov; + struct kiocb *kiocb; }; static inline struct sock_iocb *kiocb_to_siocb(struct kiocb *iocb) { - BUG_ON(sizeof(struct sock_iocb) > KIOCB_PRIVATE_SIZE); return (struct sock_iocb *)iocb->private; } static inline struct kiocb *siocb_to_kiocb(struct sock_iocb *si) { - return container_of((void *)si, struct kiocb, private); + return si->kiocb; } struct socket_alloc { Index: mm3-2.6.7/include/linux/aio.h =================================================================== --- mm3-2.6.7.orig/include/linux/aio.h 2004-06-15 22:18:54.000000000 -0700 +++ mm3-2.6.7/include/linux/aio.h 2004-06-27 15:50:40.654700112 -0700 @@ -23,8 +23,6 @@ #define KIOCB_SYNC_KEY (~0U) -#define KIOCB_PRIVATE_SIZE (24 * sizeof(long)) - /* ki_flags bits */ #define KIF_LOCKED 0 #define KIF_KICKED 1 @@ -55,6 +53,7 @@ struct kioctx *ki_ctx; /* may be NULL for sync ops */ int (*ki_cancel)(struct kiocb *, struct io_event *); long (*ki_retry)(struct kiocb *); + void (*ki_dtor)(struct kiocb *); struct list_head ki_list; /* the aio core uses this * for cancellation */ @@ -65,8 +64,7 @@ } ki_obj; __u64 ki_user_data; /* user's data for completion */ loff_t ki_pos; - - char private[KIOCB_PRIVATE_SIZE]; + void *private; }; #define is_sync_kiocb(iocb) ((iocb)->ki_key == KIOCB_SYNC_KEY) @@ -79,6 +77,7 @@ (x)->ki_filp = (filp); \ (x)->ki_ctx = &tsk->active_mm->default_kioctx; \ (x)->ki_cancel = NULL; \ + (x)->ki_dtor = NULL; \ (x)->ki_obj.tsk = tsk; \ } while (0) Index: mm3-2.6.7/net/socket.c =================================================================== --- mm3-2.6.7.orig/net/socket.c 2004-06-15 22:19:13.000000000 -0700 +++ mm3-2.6.7/net/socket.c 2004-06-27 15:50:40.662698896 -0700 @@ -548,9 +548,11 @@ int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) { struct kiocb iocb; + struct sock_iocb siocb; int ret; init_sync_kiocb(&iocb, NULL); + iocb.private = &siocb; ret = __sock_sendmsg(&iocb, sock, msg, size); if (-EIOCBQUEUED == ret) ret = wait_on_sync_kiocb(&iocb); @@ -581,15 +583,22 @@ size_t size, int flags) { struct kiocb iocb; + struct sock_iocb siocb; int ret; init_sync_kiocb(&iocb, NULL); + iocb.private = &siocb; ret = __sock_recvmsg(&iocb, sock, msg, size, flags); if (-EIOCBQUEUED == ret) ret = wait_on_sync_kiocb(&iocb); return ret; } +static void sock_aio_dtor(struct kiocb *iocb) +{ + kfree(iocb->private); +} + /* * Read data from a socket. ubuf is a user mode pointer. We make sure the user * area ubuf...ubuf+size-1 is writable before asking the protocol. @@ -598,7 +607,7 @@ static ssize_t sock_aio_read(struct kiocb *iocb, char __user *ubuf, size_t size, loff_t pos) { - struct sock_iocb *x = kiocb_to_siocb(iocb); + struct sock_iocb *x, siocb; struct socket *sock; int flags; @@ -607,6 +616,16 @@ if (size==0) /* Match SYS5 behaviour */ return 0; + if (is_sync_kiocb(iocb)) + x = &siocb; + else { + x = kmalloc(sizeof(struct sock_iocb), GFP_KERNEL); + if (!x) + return -ENOMEM; + iocb->ki_dtor = sock_aio_dtor; + } + iocb->private = x; + x->kiocb = iocb; sock = SOCKET_I(iocb->ki_filp->f_dentry->d_inode); x->async_msg.msg_name = NULL; @@ -631,7 +650,7 @@ static ssize_t sock_aio_write(struct kiocb *iocb, const char __user *ubuf, size_t size, loff_t pos) { - struct sock_iocb *x = kiocb_to_siocb(iocb); + struct sock_iocb *x, siocb; struct socket *sock; if (pos != 0) @@ -639,6 +658,16 @@ if(size==0) /* Match SYS5 behaviour */ return 0; + if (is_sync_kiocb(iocb)) + x = &siocb; + else { + x = kmalloc(sizeof(struct sock_iocb), GFP_KERNEL); + if (!x) + return -ENOMEM; + iocb->ki_dtor = sock_aio_dtor; + } + iocb->private = x; + x->kiocb = iocb; sock = SOCKET_I(iocb->ki_filp->f_dentry->d_inode); x->async_msg.msg_name = NULL; Index: mm3-2.6.7/fs/aio.c =================================================================== --- mm3-2.6.7.orig/fs/aio.c 2004-06-27 15:44:54.278357320 -0700 +++ mm3-2.6.7/fs/aio.c 2004-06-27 15:50:40.667698136 -0700 @@ -396,6 +396,8 @@ req->ki_cancel = NULL; req->ki_retry = NULL; req->ki_obj.user = NULL; + req->ki_dtor = NULL; + req->private = NULL; /* Check if the completion queue has enough free space to * accept an event from this io. @@ -436,9 +438,13 @@ static inline void really_put_req(struct kioctx *ctx, struct kiocb *req) { + if (req->ki_dtor) + req->ki_dtor(req); req->ki_ctx = NULL; req->ki_filp = NULL; req->ki_obj.user = NULL; + req->ki_dtor = NULL; + req->private = NULL; kmem_cache_free(kiocb_cachep, req); ctx->reqs_active--; From akpm@osdl.org Mon Jun 28 01:13:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 01:13:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S8Ddgi002763 for ; Mon, 28 Jun 2004 01:13:39 -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 i5S8DTZ08620; Mon, 28 Jun 2004 01:13:29 -0700 Date: Mon, 28 Jun 2004 01:12:32 -0700 From: Andrew Morton To: William Lee Irwin III Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: kiocb->private is too large for kiocb's on-stack Message-Id: <20040628011232.43acd3b8.akpm@osdl.org> In-Reply-To: <20040628080801.GO21066@holomorphy.com> References: <20040628080801.GO21066@holomorphy.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: 6375 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: 1295 Lines: 33 William Lee Irwin III wrote: > > sizeof(struct kiocb) is dangerously large for a structure commonly > allocated on-stack. This patch converts the 24*sizeof(long) field, > ->private, to a void pointer for use by file_operations entrypoints. > A ->dtor() method is added to the kiocb in order to support the release > of dynamically allocated structures referred to by ->private. > > The sole in-tree users of ->private are async network read/write, > which are not, in fact, async, and so need not handle preallocated > ->private as they would need to if ->ki_retry were ever used. The sole > truly async operations are direct IO pread()/pwrite() which do not > now use ->ki_retry(). All they would need to do in that case is to > check for ->private already being allocated for async kiocbs. > > This rips 88B off the stack on 32-bit in the common case. > > int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) > { > struct kiocb iocb; > + struct sock_iocb siocb; > int ret; > > init_sync_kiocb(&iocb, NULL); > + iocb.private = &siocb; > ret = __sock_sendmsg(&iocb, sock, msg, size); > if (-EIOCBQUEUED == ret) > ret = wait_on_sync_kiocb(&iocb); That's so much better than what we had before it ain't funny. Was this runtime tested? From wli@holomorphy.com Mon Jun 28 01:20:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 01:20:45 -0700 (PDT) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S8KJgi003683 for ; Mon, 28 Jun 2004 01:20:20 -0700 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1BerNA-0007UI-00; Mon, 28 Jun 2004 01:20:16 -0700 Date: Mon, 28 Jun 2004 01:20:16 -0700 From: William Lee Irwin III To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: kiocb->private is too large for kiocb's on-stack Message-ID: <20040628082016.GP21066@holomorphy.com> Mail-Followup-To: William Lee Irwin III , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com References: <20040628080801.GO21066@holomorphy.com> <20040628011232.43acd3b8.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040628011232.43acd3b8.akpm@osdl.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 6377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: netdev Content-Length: 305 Lines: 11 On Mon, Jun 28, 2004 at 01:12:32AM -0700, Andrew Morton wrote: > That's so much better than what we had before it ain't funny. > Was this runtime tested? Yes. Oracle exercises this, and it survives OAST. I'll write a dedicated userspace testcase for the aio operations and follow up with that. -- wli From herbert@gondor.apana.org.au Mon Jun 28 02:43:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 02:43:55 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5S9hrgi009210 for ; Mon, 28 Jun 2004 02:43: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 1Besft-0006Rp-00; Mon, 28 Jun 2004 19:43:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Besfp-0004hd-00; Mon, 28 Jun 2004 19:43:37 +1000 From: Herbert Xu To: davem@redhat.com (David S. Miller) Subject: Re: old NLMSG_OK fix Cc: hch@lst.de, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040627205133.11d37f0c.davem@redhat.com> 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: Mon, 28 Jun 2004 19:43:37 +1000 X-archive-position: 6378 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: 20 David S. Miller wrote: > On Sun, 27 Jun 2004 19:15:52 +0200 > Christoph Hellwig wrote: > >> http://oss.sgi.com/projects/netdev/archive/2000-09/msg00001.html > > It works because there is always 16 bytes of scratch at the end of an > SKB more than was allocated for the actual data. So blindly deref'ing > the nlmsg_len value is fine here. Yes but this is also used by user-space appliations where this scratch space may not exist. NETLINK messages can travel from one application to another so exploits are possible. 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 util@deuroconsult.ro Mon Jun 28 06:26:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 06:26:08 -0700 (PDT) Received: from hosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SDQ1gi025634 for ; Mon, 28 Jun 2004 06:26: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 i5SDPxKa009407; Mon, 28 Jun 2004 16:25:59 +0300 Date: Mon, 28 Jun 2004 16:25:59 +0300 (EEST) From: Catalin BOIE X-X-Sender: util@hosting.rdsbv.ro To: "David S. Miller" cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Add selective delay to sch_dealy (aka sch_ooo) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6382 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: 5776 Lines: 229 Hello! David, please apply. I tested it and works as expected. Seems Stephen doesn't have time to look over. Thank you very much. Signed-off-by: Catalin(ux aka Dino) BOIE --- linux-2.6.7-bk5.orig/net/sched/sch_delay.c 2004-06-23 12:18:00.000000000 +0300 +++ linux-2.6.7-bk5/net/sched/sch_delay.c 2004-06-24 10:41:02.000000000 +0300 @@ -7,6 +7,7 @@ * 2 of the License, or (at your option) any later version. * * Authors: Stephen Hemminger + Catalin(ux aka Dino) BOIE */ #include @@ -33,7 +34,7 @@ #include /* Network delay simulator - This scheduler adds a fixed delay to all packets. + This scheduler adds a fixed delay to all/some packets. Similar to NISTnet and BSD Dummynet. It uses byte fifo underneath similar to TBF */ @@ -41,8 +42,12 @@ struct dly_sched_data { u32 latency; u32 limit; u32 loss; + u32 gap; /* gap between packets: 0=all pkts are processed */ struct timer_list timer; struct Qdisc *qdisc; + struct sk_buff_head qooo; + u32 send_from_qooo; + u32 counter; }; /* Time stamp put into socket buffer control block */ @@ -59,6 +64,8 @@ static int dly_enqueue(struct sk_buff *s struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; int ret; + pr_debug("enqueue:\n"); + /* Random packet drop 0 => none, ~0 => all */ if (q->loss >= net_random()) { sch->stats.drops++; @@ -104,6 +111,26 @@ static unsigned int dly_drop(struct Qdis return len; } +static void dly_mod_timer(struct dly_sched_data *q, struct sk_buff *skb) +{ + struct dly_skb_cb *cb; + psched_time_t now; + long diff, delay; + + if (timer_pending(&q->timer)) + return; + + cb = (struct dly_skb_cb *)skb->cb; + PSCHED_GET_TIME(now); + diff = q->latency - PSCHED_TDIFF(now, cb->queuetime); + delay = PSCHED_US2JIFFIE(diff); + if (delay <= 0) + delay = 1; + mod_timer(&q->timer, jiffies + delay); + + pr_debug("mod_timer: Set new timer to %ld\n", jiffies + delay); +} + /* Dequeue packet. * If packet needs to be held up, then stop the * queue and set timer to wakeup later. @@ -111,37 +138,54 @@ static unsigned int dly_drop(struct Qdis static struct sk_buff *dly_dequeue(struct Qdisc *sch) { struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct sk_buff *skb; + struct sk_buff *skb, *skb2; - retry: - skb = q->qdisc->dequeue(q->qdisc); - if (skb) { - struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; - psched_time_t now; - long diff, delay; - - PSCHED_GET_TIME(now); - diff = q->latency - PSCHED_TDIFF(now, cb->queuetime); - - if (diff <= 0) { - sch->q.qlen--; - sch->flags &= ~TCQ_F_THROTTLED; - return skb; + /* test if we must dequeue from qooo */ + if (q->send_from_qooo == 1) { + q->send_from_qooo = 0; + + skb = __skb_dequeue(&q->qooo); + if (skb == NULL) { + pr_debug("dequeue: BUG! send_from_qooo == 1 and queue empty!\n"); + return NULL; } - if (q->qdisc->ops->requeue(skb, q->qdisc) != NET_XMIT_SUCCESS) { - sch->q.qlen--; - sch->stats.drops++; - goto retry; + pr_debug("dequeue: from qooo queue [%p]\n", skb); + sch->q.qlen--; + + /* set timer to next event */ + skb2 = __skb_dequeue(&q->qooo); + if (skb2) { + dly_mod_timer(q, skb2); + __skb_queue_head(&q->qooo, skb2); } - delay = PSCHED_US2JIFFIE(diff); - if (delay <= 0) - delay = 1; - mod_timer(&q->timer, jiffies+delay); + return skb; + } + + skb = q->qdisc->dequeue(q->qdisc); + if (skb == NULL) + return NULL; + + if (q->counter < q->gap) { + pr_debug("dequeue: don't touch this packet\n"); + q->counter++; - sch->flags |= TCQ_F_THROTTLED; + sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + return skb; } + + /* we must delay this packet */ + pr_debug("dequeue: mv head pkt from main to qooo and mod timer\n"); + q->send_from_qooo = 0; + dly_mod_timer(q, skb); + __skb_queue_tail(&q->qooo, skb); + sch->flags |= TCQ_F_THROTTLED; + + /* reset counter */ + q->counter = 0; + return NULL; } @@ -153,11 +197,16 @@ static void dly_reset(struct Qdisc *sch) sch->q.qlen = 0; sch->flags &= ~TCQ_F_THROTTLED; del_timer(&q->timer); + skb_queue_purge(&q->qooo); } static void dly_timer(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; + struct dly_sched_data *q = (struct dly_sched_data *)sch->data; + + pr_debug("timer: Permit sending from qooo\n"); + q->send_from_qooo = 1; sch->flags &= ~TCQ_F_THROTTLED; netif_schedule(sch->dev); @@ -205,6 +254,10 @@ static int dly_change(struct Qdisc *sch, q->latency = qopt->latency; q->limit = qopt->limit; q->loss = qopt->loss; + q->gap = qopt->gap; + + q->counter = 0; + q->send_from_qooo = 0; } return err; } @@ -221,6 +274,8 @@ static int dly_init(struct Qdisc *sch, s q->timer.data = (unsigned long) sch; q->qdisc = &noop_qdisc; + skb_queue_head_init(&q->qooo); + return dly_change(sch, opt); } @@ -231,6 +286,7 @@ static void dly_destroy(struct Qdisc *sc del_timer(&q->timer); qdisc_destroy(q->qdisc); q->qdisc = &noop_qdisc; + skb_queue_purge(&q->qooo); } static int dly_dump(struct Qdisc *sch, struct sk_buff *skb) @@ -242,6 +298,7 @@ static int dly_dump(struct Qdisc *sch, s qopt.latency = q->latency; qopt.limit = q->limit; qopt.loss = q->loss; + qopt.gap = q->gap; RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); --- linux-2.6.7-bk5.orig/include/linux/pkt_sched.h 2004-06-23 12:17:59.000000000 +0300 +++ linux-2.6.7-bk5/include/linux/pkt_sched.h 2004-06-23 14:40:16.000000000 +0300 @@ -438,5 +438,6 @@ struct tc_dly_qopt __u32 latency; __u32 limit; __u32 loss; + __u32 gap; }; #endif --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From shemminger@osdl.org Mon Jun 28 09:43:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 09:43:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SGhPgi005215 for ; Mon, 28 Jun 2004 09:43:27 -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 i5SGh7Z17407; Mon, 28 Jun 2004 09:43:08 -0700 Date: Mon, 28 Jun 2004 09:43:07 -0700 From: Stephen Hemminger To: Catalin BOIE Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Add selective delay to sch_dealy (aka sch_ooo) Message-Id: <20040628094307.6584eb12@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: 6384 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: 113 Lines: 2 I am working on an expanded version of the combined scheduler. So if you wait a couple days, it should be ready. From yoshfuji@linux-ipv6.org Mon Jun 28 10:05:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 10:05:23 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SH5Igi007933 for ; Mon, 28 Jun 2004 10:05:19 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 82A2333CE6; Tue, 29 Jun 2004 02:06:27 +0900 (JST) Date: Tue, 29 Jun 2004 02:06:27 +0900 (JST) Message-Id: <20040629.020627.76560474.yoshfuji@linux-ipv6.org> To: rmk+lkml@arm.linux.org.uk Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.6: IPv6 initialisation bug From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040628010200.A15067@flint.arm.linux.org.uk> References: <20040628010200.A15067@flint.arm.linux.org.uk> 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: 6386 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: 861 Lines: 27 In article <20040628010200.A15067@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 01:02:01 +0100), Russell King says: > Ok, I've just tried 2.6.7 out on my root-NFS'd firewall with IPv6 built > in, and it doesn't work because of the problem I described below. : > What's the solution? Bring lo up before bring others up. What does prevent you from doing this? (Do we need some bits to do this automatically?) > Is there a good reason why IPv6 uses the loopback device for local > routes? IPv6 creates kernel routes for local addresses on lo to receive packets for local address. Well, someone probably wants to have static local routes on ethX + temprary (cache) local routes on lo (as IPv4 does; correct me if I'm wrong.) But this won't work because IPv6 does DAD when we make some interface up. We need lo anyway. --yoshfuji From rmk+netdev=oss.sgi.com@arm.linux.org.uk Mon Jun 28 10:48:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 10:48:11 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SHm5gi009479 for ; Mon, 28 Jun 2004 10:48:07 -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.33) id 1Bf0EZ-0002Ce-8K; Mon, 28 Jun 2004 18:47:59 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.33) id 1Bf0EY-0005vb-D5; Mon, 28 Jun 2004 18:47:58 +0100 Date: Mon, 28 Jun 2004 18:47:58 +0100 From: Russell King To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.6: IPv6 initialisation bug Message-ID: <20040628184758.C9214@flint.arm.linux.org.uk> Mail-Followup-To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040628010200.A15067@flint.arm.linux.org.uk> <20040629.020627.76560474.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040629.020627.76560474.yoshfuji@linux-ipv6.org>; from yoshfuji@linux-ipv6.org on Tue, Jun 29, 2004 at 02:06:27AM +0900 X-archive-position: 6387 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: 1897 Lines: 49 On Tue, Jun 29, 2004 at 02:06:27AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > In article <20040628010200.A15067@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 01:02:01 +0100), Russell King says: > > > Ok, I've just tried 2.6.7 out on my root-NFS'd firewall with IPv6 built > > in, and it doesn't work because of the problem I described below. > : > > What's the solution? > > Bring lo up before bring others up. > What does prevent you from doing this? > (Do we need some bits to do this automatically?) When you use root-NFS, the kernel itself brings up the interfaces, and IPv6 immediately comes in and tries to configure itself to them, trying to create the routes. Unfortunately, the kernel doesn't bring up lo first because it doesn't know to do that. > > Is there a good reason why IPv6 uses the loopback device for local > > routes? > > IPv6 creates kernel routes for local addresses on lo to receive > packets for local address. > > Well, someone probably wants to have > static local routes on ethX + temprary (cache) local routes on lo > (as IPv4 does; correct me if I'm wrong.) This would be preferable I think - it certainly would stop systems exploding when you take lo down for whatever reason, even temporarily. Currently, if you do that, all your IPv6 local routes die off and you're left trying to forward your own local address out various itnerfaces. > But this won't work because IPv6 does DAD when we make some interface up. > We need lo anyway. Sorry, I don't understand how this has a bearing on which device the local routes are attached to. How come IPv4 can be happy having local routes attached to the individual interface, yet IPv6 can't be? -- 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 davem@redhat.com Mon Jun 28 11:24:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 11:24:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SIOVgi011208 for ; Mon, 28 Jun 2004 11:24: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 i5SIONe1016710; Mon, 28 Jun 2004 14:24: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 i5SIOM002826; Mon, 28 Jun 2004 14:24:23 -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 i5SINwo7003410; Mon, 28 Jun 2004 14:23:58 -0400 Date: Mon, 28 Jun 2004 11:22:58 -0700 From: "David S. Miller" To: Herbert Xu Cc: hch@lst.de, netdev@oss.sgi.com Subject: Re: old NLMSG_OK fix Message-Id: <20040628112258.31ed64f1.davem@redhat.com> In-Reply-To: References: <20040627205133.11d37f0c.davem@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: 6388 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: 734 Lines: 18 On Mon, 28 Jun 2004 19:43:37 +1000 Herbert Xu wrote: > David S. Miller wrote: > > On Sun, 27 Jun 2004 19:15:52 +0200 > > Christoph Hellwig wrote: > > > >> http://oss.sgi.com/projects/netdev/archive/2000-09/msg00001.html > > > > It works because there is always 16 bytes of scratch at the end of an > > SKB more than was allocated for the actual data. So blindly deref'ing > > the nlmsg_len value is fine here. > > Yes but this is also used by user-space appliations where this scratch > space may not exist. NETLINK messages can travel from one application > to another so exploits are possible. You're right, thanks for pointing this out. I'll add it to my tree. From davem@redhat.com Mon Jun 28 11:26:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 11:26:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SIQdgi011707 for ; Mon, 28 Jun 2004 11:26:40 -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 i5SIQZe1017311; Mon, 28 Jun 2004 14:26:35 -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 i5SIQY003513; Mon, 28 Jun 2004 14:26:34 -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 i5SIQ94l004385; Mon, 28 Jun 2004 14:26:10 -0400 Date: Mon, 28 Jun 2004 11:25:10 -0700 From: "David S. Miller" To: William Lee Irwin III Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kiocb->private is too large for kiocb's on-stack Message-Id: <20040628112510.509d08f7.davem@redhat.com> In-Reply-To: <20040628082016.GP21066@holomorphy.com> References: <20040628080801.GO21066@holomorphy.com> <20040628011232.43acd3b8.akpm@osdl.org> <20040628082016.GP21066@holomorphy.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: 6389 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: 542 Lines: 16 On Mon, 28 Jun 2004 01:20:16 -0700 William Lee Irwin III wrote: > On Mon, Jun 28, 2004 at 01:12:32AM -0700, Andrew Morton wrote: > > That's so much better than what we had before it ain't funny. > > Was this runtime tested? > > Yes. Oracle exercises this, and it survives OAST. > > I'll write a dedicated userspace testcase for the aio operations and > follow up with that. This all looks fine to me. Andrew, would you like me to push this patch along or did you already plan to take care of it. Nice work William. From olh@suse.de Mon Jun 28 11:30:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 11:30:08 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SITsgi012165 for ; Mon, 28 Jun 2004 11:29: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 16FFA7F7069; Mon, 28 Jun 2004 20:18:44 +0200 (CEST) Date: Mon, 28 Jun 2004 20:18:43 +0200 From: Olaf Hering To: Andrew Morton , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] signed bug in net/decnet/dn_nsp_in.c dn_nsp_linkservice() Message-ID: <20040628181843.GA15021@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5SITsgi012165 X-archive-position: 6390 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: 589 Lines: 23 net/decnet/dn_nsp_in.c:534: warning: comparison is always false due to limited range of data type char can be either signed or unsigned, depending on the target system. patch is against 2.6.7-bk11 --- ./net/decnet/dn_nsp_in.c +++ ./net/decnet/dn_nsp_in.c 2004/06/28 18:11:40 @@ -504,7 +504,7 @@ struct dn_scp *scp = DN_SK(sk); unsigned short segnum; unsigned char lsflags; - char fcval; + signed char fcval; int wake_up = 0; char *ptr = skb->data; unsigned char fctype = scp->services_rem & NSP_FC_MASK; -- USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG From niv@us.ibm.com Mon Jun 28 12:42:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 12:42:52 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SJgfgi018284 for ; Mon, 28 Jun 2004 12:42:47 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5SJgXur338362 for ; Mon, 28 Jun 2004 15:42:34 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5SJgXFr710954 for ; Mon, 28 Jun 2004 13:42:33 -0600 Message-ID: <40E07531.7080500@us.ibm.com> Date: Mon, 28 Jun 2004 12:44:49 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [Fwd: [Bug 2971] New: Oops: tcp_retransmit_skb] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6392 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: 3835 Lines: 113 We've been looking into the ASSERTION failure, but this is the first I've seen this oops. Anyone run into this before? thanks, Nivedita -------- Original Message -------- Subject: [Bug 2971] New: Oops: tcp_retransmit_skb Date: Sun, 27 Jun 2004 18:45:55 -0700 From: bugme-daemon@osdl.org To: niv@us.ibm.com http://bugme.osdl.org/show_bug.cgi?id=2971 Summary: Oops: tcp_retransmit_skb Kernel Version: 2.6.6 Status: NEW Severity: high Owner: niv@us.ibm.com Submitter: ranko@spidernet.net Distribution: Fedora Hardware Environment: Intel SHG2 Xeon Motherboard, 2 x 2.40GHz Xeon CPU, 4GB RAM, 1 x e100, 1 x e1000 (inactive) lspci output: 00:00.0 Host bridge: ServerWorks CMIC-LE (rev 13) 00:00.1 Host bridge: ServerWorks CMIC-LE 00:00.2 Host bridge: ServerWorks: Unknown device 0000 00:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0d) 00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93) 00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93) 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05) 00:0f.3 Host bridge: ServerWorks GCLE Host Bridge 00:11.0 Host bridge: ServerWorks: Unknown device 0101 (rev 03) 00:11.2 Host bridge: ServerWorks: Unknown device 0101 (rev 03) 01:04.0 Ethernet controller: Intel Corp. 82544GC Gigabit Ethernet Controller (LOM) (rev 02) 02:09.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 02:09.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) *Gigabit is not currently active (unplugged) Software Environment: Relatively busy caching proxy machine Problem Description: Unable to handle kernel paging request at virtual address 22fa7b7d printing eip: c02dab10 *pde = 00000000 Oops: 0000 [#1] SMP CPU: 1 EIP: 0060:[] Not tainted EFLAGS: 00010213 (2.6.6) EIP is at pskb_copy+0xe0/0x180 eax: e478de00 ebx: f54fdc80 ecx: e478de00 edx: 22fa7b7d esi: 00000000 edi: e478d8ec ebp: e0f89480 esp: f7d0bec0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=f7d0a000 task=f7d0f0e0) Stack: e0f89480 f34d1800 f34d19e8 ffffff8f c030551d c02fdac6 000004ec f34d1800 f34d19e8 f34d1864 f7d0bf3c c03079dd f665e080 00000001 f6085970 c2f96ce0 f7d0bf30 00000292 6e704540 001112a0 00000001 f34d1800 1e6ef2b0 c2f976e0 Call Trace: [] tcp_retransmit_skb+0x1bd/0x310 [] tcp_enter_loss+0x66/0x230 [] tcp_retransmit_timer+0xed/0x410 [] tcp_write_timer+0xa9/0xe0 [] tcp_write_timer+0x0/0xe0 [] run_timer_softirq+0xd4/0x170 [] __do_softirq+0xb4/0xc0 [] do_softirq+0x2d/0x30 [] smp_apic_timer_interrupt+0xdc/0x140 [] apic_timer_interrupt+0x1a/0x20 [] default_idle+0x0/0x40 [] default_idle+0x29/0x40 [] cpu_idle+0x3b/0x50 [] serial8250_console_write+0x0/0x200 [] serial8250_console_write+0x0/0x200 [] __call_console_drivers+0x57/0x60 [] call_console_drivers+0x7f/0x100 Code: 8b 02 a9 00 00 08 00 75 70 f0 ff 42 04 8b 85 a4 00 00 00 46 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing <0>Rebooting in 30 seconds..Press any key to continue. Also found in logs (though few hours before the crash - not sure if related): KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1568) (...lots of times) Steps to reproduce: Nothing special except that it happened during relatively high network activity. If I can be of any further help just let me know. Thanks, Ranko ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From wgshi2002@yahoo.ca Mon Jun 28 12:45:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 12:45:22 -0700 (PDT) Received: from web54108.mail.yahoo.com (web54108.mail.yahoo.com [206.190.37.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SJjIgi018735 for ; Mon, 28 Jun 2004 12:45:18 -0700 Message-ID: <20040628194452.51849.qmail@web54108.mail.yahoo.com> Received: from [129.128.209.16] by web54108.mail.yahoo.com via HTTP; Mon, 28 Jun 2004 15:44:52 EDT Date: Mon, 28 Jun 2004 15:44:52 -0400 (EDT) From: Weiguang Shi Subject: /proc/sys/net/ipv4/tcp_* To: netdev linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wgshi2002@yahoo.ca Precedence: bulk X-list: netdev Content-Length: 451 Lines: 15 Hi, Where can I find a more readable documentation than the code for these files (for kernel 2.4.20, and yes RH9)? In particular, does tcp_frto enable/disable the F-RTO proposed in the paper (ACM SIGCOMM CCR) by Sarolahti, Kojo, and Raatikainen? A third question: what does FLAG_ECE mean in tcp_input.c? Thank you! Weiguang ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From chengjin@cs.caltech.edu Mon Jun 28 12:52:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 12:52:43 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SJqdgi019579 for ; Mon, 28 Jun 2004 12:52:39 -0700 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id D9D3ADF2F5; Mon, 28 Jun 2004 12:52:38 -0700 (PDT) Received: by orchestra.cs.caltech.edu (Postfix, from userid 20269) id 5BAC89BC26; Mon, 28 Jun 2004 12:52:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by orchestra.cs.caltech.edu (Postfix) with ESMTP id 2FD7A9BC28; Mon, 28 Jun 2004 12:52:37 -0700 (PDT) Date: Mon, 28 Jun 2004 12:52:37 -0700 (PDT) From: Cheng Jin To: Weiguang Shi Cc: netdev linux Subject: Re: /proc/sys/net/ipv4/tcp_* In-Reply-To: <20040628194452.51849.qmail@web54108.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Content-Length: 345 Lines: 13 > Where can I find a more readable documentation than the code for these files > (for kernel 2.4.20, and yes RH9)? http://datatag.web.cern.ch/datatag/publications.html see "A Map of the Networking Code in Linux Kernel 2.4.20" > A third question: what does FLAG_ECE mean in tcp_input.c? if an ack carries explicit congestion notification. From brazilnut@us.ibm.com Mon Jun 28 13:26:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 13:26:49 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SKQbgi021051 for ; Mon, 28 Jun 2004 13:26:46 -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.2) with ESMTP id i5SKQRtf519262; Mon, 28 Jun 2004 16:26:28 -0400 Received: from DYN318364BLD.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 i5SKQL9s388062; Mon, 28 Jun 2004 14:26:21 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5SKPv211077; Mon, 28 Jun 2004 13:25:57 -0700 From: Don Fry Message-Id: <200406282025.i5SKPv211077@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 6 2.6.7-bk11] pcnet32: correctly program bcr32. To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 28 Jun 2004 13:25:56 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6395 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: 2208 Lines: 57 The pcnet32 driver was not correctly enabling MII autonegotiation after booting when ppc firmware forced the speed/duplex mode of the chip. After several conversations with AMD this patch corrects the problem. I have tested this on hardware I have available (ia32 and ppc64) but I would like wider audience testing of this patch. Signed-off-by: Don Fry --- linux-2.6.7-bk11/drivers/net/home.pcnet32.c Mon Jun 28 12:04:07 2004 +++ linux-2.6.7-bk11/drivers/net/pcnet32.c Mon Jun 28 12:08:57 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30g" -#define DRV_RELDATE "06.22.2004" +#define DRV_VERSION "1.30h" +#define DRV_RELDATE "06.24.2004" #define PFX DRV_NAME ": " static const char *version = @@ -253,6 +253,7 @@ static int homepna[MAX_UNITS]; * and Brian Murphy . * v1.30g 22 Jun 2004 Patrick Simmons added option * homepna for selecting HomePNA mode for PCNet/Home 79C978. + * v1.30h 24 Jun 2004 Don Fry correctly select auto, speed, duplex in bcr32. */ @@ -1422,9 +1423,13 @@ pcnet32_open(struct net_device *dev) val |= 0x10; lp->a.write_csr (ioaddr, 124, val); + /* 24 Jun 2004 according AMD, in order to change the PHY, + * DANAS (or DISPM for 79C976) must be set; then select the speed, + * duplex, and/or enable auto negotiation, and clear DANAS */ if (lp->mii && !(lp->options & PCNET32_PORT_ASEL)) { + lp->a.write_bcr(ioaddr, 32, lp->a.read_bcr(ioaddr, 32) | 0x0080); /* disable Auto Negotiation, set 10Mpbs, HD */ - val = lp->a.read_bcr (ioaddr, 32) & ~0x38; + val = lp->a.read_bcr(ioaddr, 32) & ~0xb8; if (lp->options & PCNET32_PORT_FD) val |= 0x10; if (lp->options & PCNET32_PORT_100) @@ -1432,6 +1437,7 @@ pcnet32_open(struct net_device *dev) lp->a.write_bcr (ioaddr, 32, val); } else { if (lp->options & PCNET32_PORT_ASEL) { + lp->a.write_bcr(ioaddr, 32, lp->a.read_bcr(ioaddr, 32) | 0x0080); /* enable auto negotiate, setup, disable fd */ val = lp->a.read_bcr(ioaddr, 32) & ~0x98; val |= 0x20; -- Don Fry brazilnut@us.ibm.com From wgshi2002@yahoo.ca Mon Jun 28 13:30:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 13:30:01 -0700 (PDT) Received: from web54103.mail.yahoo.com (web54103.mail.yahoo.com [206.190.37.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SKTxgi021503 for ; Mon, 28 Jun 2004 13:30:00 -0700 Message-ID: <20040628202954.14349.qmail@web54103.mail.yahoo.com> Received: from [129.128.209.16] by web54103.mail.yahoo.com via HTTP; Mon, 28 Jun 2004 16:29:54 EDT Date: Mon, 28 Jun 2004 16:29:54 -0400 (EDT) From: Weiguang Shi Subject: Re: /proc/sys/net/ipv4/tcp_* To: Cheng Jin Cc: netdev linux In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wgshi2002@yahoo.ca Precedence: bulk X-list: netdev Content-Length: 437 Lines: 15 Thanks Cheng. --- Cheng Jin wrote: > > > > Where can I find a more readable documentation than the code for these files > > (for kernel 2.4.20, and yes RH9)? > > http://datatag.web.cern.ch/datatag/publications.html > > see "A Map of the Networking Code in Linux Kernel 2.4.20" Nice. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From ganesh.venkatesan@intel.com Mon Jun 28 15:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 15:12:56 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SMCngi030641 for ; Mon, 28 Jun 2004 15:12:50 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) 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 i5SFCtck003500; Mon, 28 Jun 2004 15:13:02 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5SM7FNY015789; Mon, 28 Jun 2004 22:07:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062815114010324 ; Mon, 28 Jun 2004 15:11:46 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 15:11:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: e1000_clean_tx_ring Date: Mon, 28 Jun 2004 15:11:04 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E01967ADD@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000_clean_tx_ring Thread-Index: AcRaQmSgv6hLxi+3R4e1diKn4qeaPwDGlujg From: "Venkatesan, Ganesh" To: "Anton Blanchard" , Cc: "cramerj" , "Ronciak, John" X-OriginalArrivalTime: 28 Jun 2004 22:11:06.0013 (UTC) FILETIME=[CEBDB4D0:01C45D5C] 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 i5SMCngi030641 X-archive-position: 6397 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 Anton: We will integrate this patch into the next release of our driver. Thanks, ganesh ------------------------------------------------- Ganesh Venkatesan Network/Storage Division, Hillsboro, OR -----Original Message----- From: Anton Blanchard [mailto:anton@samba.org] Sent: Thursday, June 24, 2004 4:23 PM To: netdev@oss.sgi.com Cc: cramerj; Ronciak, John; Venkatesan, Ganesh Subject: e1000_clean_tx_ring Hi, I was looking over the e1000 driver and noticed what I think is a bug in e1000_clean_tx_ring. We wouldnt call pci_unmap_page on tx ring entries that didnt have ->skb filled, eg zero copy packets. This is on latest 2.6 BK. Anton ===== e1000_main.c 1.120 vs edited ===== --- 1.120/drivers/net/e1000/e1000_main.c Sat Jun 19 10:00:00 2004 +++ edited/e1000_main.c Thu Jun 24 02:16:42 2004 @@ -1070,14 +1070,19 @@ for(i = 0; i < tx_ring->count; i++) { buffer_info = &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); - dev_kfree_skb(buffer_info->skb); + buffer_info->dma = NULL; + } + + if (buffer_info->skb) { + + dev_kfree_skb_any(buffer_info->skb); buffer_info->skb = NULL; } From brazilnut@us.ibm.com Mon Jun 28 16:08:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 16:08:59 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SN8lgi000598 for ; Mon, 28 Jun 2004 16:08:53 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5SN8bDk668534; Mon, 28 Jun 2004 19:08:37 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5SN9j6G082292; Mon, 28 Jun 2004 19:09:45 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i5SN8AB11334; Mon, 28 Jun 2004 16:08:10 -0700 From: Don Fry Message-Id: <200406282308.i5SN8AB11334@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 7 2.6.7-bk11] pcnet32: change to use module_param To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 28 Jun 2004 16:08:09 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6398 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 Change the pcnet32 driver to use module_param and module_param_array. --- linux-2.6.7-bk11/drivers/net/half.pcnet32.c Mon Jun 28 12:08:57 2004 +++ linux-2.6.7-bk11/drivers/net/pcnet32.c Mon Jun 28 15:02:23 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.30h" -#define DRV_RELDATE "06.24.2004" +#define DRV_VERSION "1.30i" +#define DRV_RELDATE "06.28.2004" #define PFX DRV_NAME ": " static const char *version = @@ -46,6 +46,7 @@ DRV_NAME ".c:v" DRV_VERSION " " DRV_RELD #include #include #include +#include #include #include @@ -254,6 +255,7 @@ static int homepna[MAX_UNITS]; * v1.30g 22 Jun 2004 Patrick Simmons added option * homepna for selecting HomePNA mode for PCNet/Home 79C978. * v1.30h 24 Jun 2004 Don Fry correctly select auto, speed, duplex in bcr32. + * v1.30i 28 Jun 2004 Don Fry change to use module_param. */ @@ -2258,22 +2260,28 @@ static struct pci_driver pcnet32_driver .id_table = pcnet32_pci_tbl, }; -MODULE_PARM(debug, "i"); +/* An additional parameter that may be passed in... */ +static int debug = -1; +static int tx_start_pt = -1; +static int pcnet32_have_pci; +static int num_params; + +module_param(debug, int, 0); MODULE_PARM_DESC(debug, DRV_NAME " debug level"); -MODULE_PARM(max_interrupt_work, "i"); +module_param(max_interrupt_work, int, 0); MODULE_PARM_DESC(max_interrupt_work, DRV_NAME " maximum events handled per interrupt"); -MODULE_PARM(rx_copybreak, "i"); +module_param(rx_copybreak, int, 0); MODULE_PARM_DESC(rx_copybreak, DRV_NAME " copy breakpoint for copy-only-tiny-frames"); -MODULE_PARM(tx_start_pt, "i"); +module_param(tx_start_pt, int, 0); MODULE_PARM_DESC(tx_start_pt, DRV_NAME " transmit start point (0-3)"); -MODULE_PARM(pcnet32vlb, "i"); +module_param(pcnet32vlb, int, 0); MODULE_PARM_DESC(pcnet32vlb, DRV_NAME " Vesa local bus (VLB) support (0/1)"); -MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); +module_param_array(options, int, num_params, 0); MODULE_PARM_DESC(options, DRV_NAME " initial option setting(s) (0-15)"); -MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); +module_param_array(full_duplex, int, num_params, 0); MODULE_PARM_DESC(full_duplex, DRV_NAME " full duplex setting(s) (1)"); /* Module Parameter for HomePNA cards added by Patrick Simmons, 2004 */ -MODULE_PARM(homepna,"1-" __MODULE_STRING(MAX_UNITS) "i"); +module_param_array(homepna, int, num_params, 0); MODULE_PARM_DESC(homepna, DRV_NAME " mode for 79C978 cards (1 for HomePNA, 0 for Ethernet, default Ethernet"); MODULE_AUTHOR("Thomas Bogendoerfer"); @@ -2282,11 +2290,6 @@ MODULE_LICENSE("GPL"); #define PCNET32_MSG_DEFAULT (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) -/* An additional parameter that may be passed in... */ -static int debug = -1; -static int tx_start_pt = -1; -static int pcnet32_have_pci; - static int __init pcnet32_init_module(void) { printk(KERN_INFO "%s", version); -- Don Fry brazilnut@us.ibm.com From herbert@gondor.apana.org.au Mon Jun 28 16:15:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 16:15:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5SNFMgi001117 for ; Mon, 28 Jun 2004 16:15: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 1Bf5Kl-0004du-00; Tue, 29 Jun 2004 09:14:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bf5Kh-0000nW-00; Tue, 29 Jun 2004 09:14:39 +1000 Date: Tue, 29 Jun 2004 09:14:39 +1000 To: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Check connect address in NETLINK Message-ID: <20040628231439.GA3021@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6399 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 Hi: The recent thread on NLMSG_OK has reminded me about an old problem with NETLINK. The problem is that any user on the system can launch a DoS attack on any NETLINK application by flooding its NETLINK address with packets. This will easily fill up the receive queue of the destination application and therefore cause legitimate packets from the kernel or elsewhere to be dropped. The solution seems simple. We already have a connect(2) call for NETLINK sockets. So why don't we check the connected address of the destination socket against the address of the sender before putting the packet on the queue? Any comments before I go ahead and code 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 davem@redhat.com Mon Jun 28 17:30:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 17:30:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T0Ungi006718 for ; Mon, 28 Jun 2004 17:30:49 -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 i5T0Ufe1015520; Mon, 28 Jun 2004 20:30: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 i5T0Uf019413; Mon, 28 Jun 2004 20:30:41 -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 i5T0UG8r011598; Mon, 28 Jun 2004 20:30:16 -0400 Date: Mon, 28 Jun 2004 17:30:39 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-Id: <20040628173039.19e61bb4.davem@redhat.com> In-Reply-To: <20040628231439.GA3021@gondor.apana.org.au> References: <20040628231439.GA3021@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: 6400 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 Tue, 29 Jun 2004 09:14:39 +1000 Herbert Xu wrote: > The solution seems simple. We already have a connect(2) call for > NETLINK sockets. So why don't we check the connected address of > the destination socket against the address of the sender before > putting the packet on the queue? > > Any comments before I go ahead and code it? This really won't break any existing legitimate cases? Are you sure? From garzik@havoc.gtf.org Mon Jun 28 17:44:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 17:44:15 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T0i3gi007453 for ; Mon, 28 Jun 2004 17:44:03 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 65C91758D; Mon, 28 Jun 2004 20:16:29 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5T0GSmK025202; Mon, 28 Jun 2004 20:16:28 -0400 Date: Mon, 28 Jun 2004 20:16:28 -0400 From: Jeff Garzik To: "David S. Miller" Cc: Chris Wedgwood , chas@cmf.nrl.navy.mil, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: fix sparse checker warnings Message-ID: <20040629001628.GB23878@havoc.gtf.org> References: <200406262245.i5QMjn65009470@ginger.cmf.nrl.navy.mil> <20040626225230.GA12698@taniwha.stupidest.org> <20040626162641.00786ed6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040626162641.00786ed6.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 6401 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 On Sat, Jun 26, 2004 at 04:26:41PM -0700, David S. Miller wrote: > On Sat, 26 Jun 2004 15:52:30 -0700 > Chris Wedgwood wrote: > > > > +++ b/net/atm/br2684.c 2004-06-22 14:04:02 -07:00 > > > @@ -562,7 +562,7 @@ > > > atmvcc->push = br2684_push; > > > skb_queue_head_init(©); > > > skb_migrate(&atmvcc->sk->sk_receive_queue, ©); > > > > > - - while ((skb = skb_dequeue(©))) { > > > + while ((skb = skb_dequeue(©)) != NULL) { > > > > I know it's a matter of style, but I really hate the 'assignment in > > conditional' warning sparse spews out, especially when many people, > > myself included really do write while ((a = b)) --- the extra > > parentheses as a compromise to keep gcc quiet. > > I think warning for the ((a=b)) case is annoying but not annoying > enough to fight against it :) FWIW I take a tangential position on the issue: it causes a fuckton of code churn From yoshfuji@linux-ipv6.org Mon Jun 28 17:57:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 17:58:02 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T0vvgi008273 for ; Mon, 28 Jun 2004 17:57:58 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 470C633CE6; Tue, 29 Jun 2004 09:59:06 +0900 (JST) Date: Tue, 29 Jun 2004 09:59:03 +0900 (JST) Message-Id: <20040629.095903.58985982.yoshfuji@linux-ipv6.org> To: rmk+lkml@arm.linux.org.uk Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.6.6: IPv6 initialisation bug From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040628184758.C9214@flint.arm.linux.org.uk> References: <20040628010200.A15067@flint.arm.linux.org.uk> <20040629.020627.76560474.yoshfuji@linux-ipv6.org> <20040628184758.C9214@flint.arm.linux.org.uk> 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: 6402 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 <20040628184758.C9214@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 18:47:58 +0100), Russell King says: > On Tue, Jun 29, 2004 at 02:06:27AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > > In article <20040628010200.A15067@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 01:02:01 +0100), Russell King says: > > > > > Ok, I've just tried 2.6.7 out on my root-NFS'd firewall with IPv6 built > > > in, and it doesn't work because of the problem I described below. > > : > > > What's the solution? > > > > Bring lo up before bring others up. > > What does prevent you from doing this? > > (Do we need some bits to do this automatically?) > > When you use root-NFS, the kernel itself brings up the interfaces, > and IPv6 immediately comes in and tries to configure itself to them, > trying to create the routes. > > Unfortunately, the kernel doesn't bring up lo first because it > doesn't know to do that. Okay, would you try the following patch, please? D: Bring loopback device up first Signed-Off-By: Hideaki YOSHIFUJI ===== net/ipv4/ipconfig.c 1.38 vs edited ===== --- 1.38/net/ipv4/ipconfig.c 2004-06-23 09:06:18 +09:00 +++ edited/net/ipv4/ipconfig.c 2004-06-29 09:53:36 +09:00 @@ -183,7 +183,14 @@ last = &ic_first_dev; rtnl_shlock(); + + /* bring loopback device up first */ + if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0) + printk(KERN_ERR "IP-Config: Failed to open %s\n", loopback_dev.name); + for (dev = dev_base; dev; dev = dev->next) { + if (dev == &loopback_dev) + continue; if (user_dev_name[0] ? !strcmp(dev->name, user_dev_name) : (!(dev->flags & IFF_LOOPBACK) && (dev->flags & (IFF_POINTOPOINT|IFF_BROADCAST)) && -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From wli@holomorphy.com Mon Jun 28 19:02:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 19:02:21 -0700 (PDT) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T22Fgi010544 for ; Mon, 28 Jun 2004 19:02:15 -0700 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1Bf7wm-0002Q0-00; Mon, 28 Jun 2004 19:02:08 -0700 Date: Mon, 28 Jun 2004 19:02:08 -0700 From: William Lee Irwin III To: Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: kiocb->private is too large for kiocb's on-stack Message-ID: <20040629020208.GJ21066@holomorphy.com> Mail-Followup-To: William Lee Irwin III , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com References: <20040628080801.GO21066@holomorphy.com> <20040628011232.43acd3b8.akpm@osdl.org> <20040628082016.GP21066@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040628082016.GP21066@holomorphy.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 6403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: netdev /* On Mon, Jun 28, 2004 at 01:12:32AM -0700, Andrew Morton wrote: >> That's so much better than what we had before it ain't funny. >> Was this runtime tested? On Mon, Jun 28, 2004 at 01:20:16AM -0700, William Lee Irwin III wrote: > Yes. Oracle exercises this, and it survives OAST. > I'll write a dedicated userspace testcase for the aio operations and > follow up with that. This is pretty damn mindless but seems to pound on the stuff. Maybe something better can be devised (e.g. passing msgs around in a ring). -- wli */ #include #include #include #include #include #include #include #include #include #include #include #include #include #define die() \ do { \ int __err = errno; \ perror(__FUNCTION__); \ fprintf(stderr, "dead in %s() at %s:%d errno = %d\n", \ __FUNCTION__, __FILE__, __LINE__, __err); \ abort(); \ } while (0) pid_t gettid(void) { return syscall(__NR_gettid); } long io_submit(aio_context_t context, long n, struct iocb **iocbs) { return syscall(__NR_io_submit, context, n, iocbs); } long io_setup(unsigned n, aio_context_t *context) { return syscall(__NR_io_setup, n, context); } long io_getevents(aio_context_t context, long min, long n, struct io_event *events, struct timespec *ts) { return syscall(__NR_io_getevents, context, min, n, events, ts); } int epoll_add(int epfd, int fd, struct epoll_event *event) { return epoll_ctl(epfd, EPOLL_CTL_ADD, fd, event); } static void *client(void *arg) { int n = 0, *fds = arg; pthread_t id = pthread_self(); while (1) { write(fds[1], &id, sizeof(pthread_t)); read(fds[1], &id, sizeof(pthread_t)); ++n; if (!(n % (1 << 16))) printf("boo from %d\n", gettid()); } } int main(int argc, char * const argv[]) { long i, j, k, nr_clients; pthread_t *clients; int *svs, epfd; struct epoll_event *events; aio_context_t context = 0; struct iocb *iocbs, **iocbps; struct io_event *io_events; pthread_t *bufs; if (argc != 2) return EXIT_FAILURE; nr_clients = strtol(argv[1], NULL, 0); if (nr_clients >= INT_MAX || nr_clients < 0) return EXIT_FAILURE; if ((size_t)nr_clients >= SIZE_MAX/sizeof(pthread_t)) return EXIT_FAILURE; if ((size_t)nr_clients >= SIZE_MAX/(2*sizeof(int))) return EXIT_FAILURE; if ((size_t)nr_clients >= SIZE_MAX/(2*sizeof(struct iocb))) return EXIT_FAILURE; if ((size_t)nr_clients >= SIZE_MAX/(2*sizeof(struct iocb *))) return EXIT_FAILURE; if ((size_t)nr_clients >= SIZE_MAX/(2*sizeof(struct io_event))) return EXIT_FAILURE; if (!(bufs = calloc(nr_clients, 2*sizeof(pthread_t)))) return EXIT_FAILURE; if (!(clients = calloc(nr_clients, sizeof(pthread_t)))) { die(); goto free_bufs; } if (!(svs = calloc(nr_clients, 2*sizeof(int)))) { die(); goto free_clients; } if (!(events = calloc(nr_clients, sizeof(struct epoll_event)))) { die(); goto free_svs; } if (!(iocbs = calloc(nr_clients, 2*sizeof(struct iocb)))) { die(); goto free_events; } if (!(iocbps = calloc(nr_clients, 2*sizeof(struct iocb *)))) { die(); goto free_iocbs; } if (!(io_events = calloc(nr_clients, sizeof(struct io_event)))) { die(); goto free_iocbps; } memset(clients, 0, sizeof(pthread_t)*nr_clients); memset(svs, 0, 2*sizeof(int)*nr_clients); memset(iocbs, 0, 2*sizeof(struct iocb)*nr_clients); memset(iocbps, 0, 2*sizeof(struct iocb *)*nr_clients); memset(io_events, 0, 2*sizeof(struct io_event)*nr_clients); if ((epfd = epoll_create(nr_clients)) < 0) { die(); goto free_io_events; } if (io_setup(nr_clients, &context)) { die(); goto free_io_events; } for (i = 0; i < nr_clients; ++i) { struct epoll_event event = { .events = EPOLLIN|EPOLLET, .data.ptr = &svs[2*i], }; if (socketpair(AF_UNIX, SOCK_STREAM, 0, &svs[2*i])) { die(); } if (epoll_add(epfd, svs[2*i], &event)) die(); if (pthread_create(&clients[i], NULL, client, &svs[2*i])) abort(); } while (1) { struct timespec ts = { .tv_sec = 0, .tv_nsec = 0, }; j = epoll_wait(epfd, events, nr_clients, 0); k = io_getevents(context, 1, nr_clients, io_events, &ts); for (i = 0; i < k; ++i) { struct iocb *cb = (struct iocb *)(unsigned long)io_events[i].obj; cb->aio_data = 0; if (cb->aio_lio_opcode == IOCB_CMD_PREAD) bufs[2*(cb - iocbs)+1] = bufs[2*(cb - iocbs)]; } for (i = 0; i < j; ++i) { int m, n = ((int *)events[i].data.ptr - svs)/2; m = (n + 1) % nr_clients; bufs[2*i+1] = clients[m]; iocbs[2*n].aio_lio_opcode = IOCB_CMD_PREAD; iocbs[2*n+1].aio_lio_opcode = IOCB_CMD_PWRITE; iocbs[2*n].aio_fildes = svs[2*n]; iocbs[2*n+1].aio_fildes = svs[2*n]; iocbs[2*n].aio_buf = (unsigned long)&bufs[2*i]; iocbs[2*n+1].aio_buf = (unsigned long)&bufs[2*i+1]; iocbs[2*n].aio_data = (unsigned long)&bufs[2*i]; iocbs[2*n+1].aio_data = (unsigned long)&bufs[2*i+1]; iocbs[2*n].aio_nbytes = sizeof(pthread_t); iocbs[2*n+1].aio_nbytes = sizeof(pthread_t); iocbs[2*n].aio_offset = 0; iocbs[2*n+1].aio_offset = 0; iocbps[2*i] = &iocbs[2*n]; iocbps[2*i+1] = &iocbs[2*n+1]; } if (j) io_submit(context, 2*j, iocbps); } free_io_events: free(io_events); free_iocbps: free(iocbps); free_iocbs: free(iocbs); free_events: free(events); free_svs: free(svs); free_clients: free(clients); free_bufs: free(bufs); die(); } From herbert@gondor.apana.org.au Mon Jun 28 19:10:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 19:10:07 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T2A0gi011232 for ; Mon, 28 Jun 2004 19:10: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 1Bf83l-0005Rh-00; Tue, 29 Jun 2004 12:09:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bf83i-00013A-00; Tue, 29 Jun 2004 12:09:18 +1000 Date: Tue, 29 Jun 2004 12:09:18 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040629020918.GA4021@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040628173039.19e61bb4.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040628173039.19e61bb4.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6404 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 Mon, Jun 28, 2004 at 05:30:39PM -0700, David S. Miller wrote: > > This really won't break any existing legitimate cases? > Are you sure? I would've thought that it shouldn't break anything. But let me have a look around and get back to you. 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 Mon Jun 28 23:06:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Jun 2004 23:06:44 -0700 (PDT) Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T66egi022912 for ; Mon, 28 Jun 2004 23:06:40 -0700 Received: from unknown (HELO core-wl.prvt.inr.net) (dtor?core@ameritech.net@68.72.45.79 with plain) by smtp807.mail.sc5.yahoo.com with SMTP; 29 Jun 2004 06:06:39 -0000 From: Dmitry Torokhov To: netdev@oss.sgi.com Subject: [PATCH] sch_prio - fix compile warning + some logic rearrangement in enqueue Date: Tue, 29 Jun 2004 01:06:36 -0500 User-Agent: KMail/1.6.2 Cc: "David S. Miller" , Jamal Hadi Salim MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406290106.38304.dtor_core@ameritech.net> X-archive-position: 6405 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 Hi, When CONFIG_NET_CLS_ACT is not set 'result' variable in prio_classify is unused. Also I was looking over the rest of the module and had hard time understanding the logic in prio_enqueue - I rearranged it a bit for better readability. Plus there are some formatting changes. Please consider for inclusion. -- Dmitry =================================================================== ChangeSet@1.1875, 2004-06-29 00:45:12-05:00, dtor_core@ameritech.net NET: sch_prio - fix compile warning in prio_classify - rearrange prio_enqueue conditional compilation maze - minor formatting changes Signed-off-by: Dmitry Torokhov sch_prio.c | 30 ++++++++++++++---------------- 1 files changed, 14 insertions(+), 16 deletions(-) =================================================================== diff -Nru a/net/sched/sch_prio.c b/net/sched/sch_prio.c --- a/net/sched/sch_prio.c 2004-06-29 00:58:52 -05:00 +++ b/net/sched/sch_prio.c 2004-06-29 00:58:52 -05:00 @@ -47,20 +47,19 @@ }; -struct Qdisc *prio_classify(struct sk_buff *skb, struct Qdisc *sch,int *r) +struct Qdisc *prio_classify(struct sk_buff *skb, struct Qdisc *sch, int *r) { struct prio_sched_data *q = (struct prio_sched_data *)sch->data; struct tcf_result res; u32 band; - int result = 0; band = skb->priority; if (TC_H_MAJ(skb->priority) != sch->handle) { #ifdef CONFIG_NET_CLS_ACT - *r = result = tc_classify(skb, q->filter_list, &res); + *r = tc_classify(skb, q->filter_list, &res); - switch (result) { + switch (*r) { case TC_ACT_SHOT: case TC_ACT_STOLEN: case TC_ACT_QUEUED: @@ -70,22 +69,22 @@ case TC_ACT_OK: case TC_ACT_UNSPEC: default: - break; + break; }; - if (!q->filter_list ) { + if (!q->filter_list) { #else if (!q->filter_list || tc_classify(skb, q->filter_list, &res)) { #endif if (TC_H_MAJ(band)) band = 0; - return q->queues[q->prio2band[band&TC_PRIO_MAX]]; + return q->queues[q->prio2band[band & TC_PRIO_MAX]]; } band = res.classid; } band = TC_H_MIN(band) - 1; if (band > q->bands) - return q->queues[q->prio2band[0]]; + band = q->prio2band[0]; return q->queues[band]; } @@ -112,17 +111,16 @@ } dropped: + #ifdef CONFIG_NET_CLS_ACT - if (TC_ACT_SHOT == ret || NET_XMIT_DROP == ret) { -#endif - sch->stats.drops++; - return NET_XMIT_DROP; -#ifdef CONFIG_NET_CLS_ACT - } else { - sch->stats.overlimits++; /* abuse, but noone uses it */ - return NET_XMIT_BYPASS; /* we dont want to confuse TCP */ + if (ret != TC_ACT_SHOT && ret != NET_XMIT_DROP) { + sch->stats.overlimits++; /* abuse, but noone uses it */ + return NET_XMIT_BYPASS; /* we dont want to confuse TCP */ } #endif + + sch->stats.drops++; + return NET_XMIT_DROP; } From david@dgreaves.com Tue Jun 29 01:08:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 01:08:47 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T88igi031003 for ; Tue, 29 Jun 2004 01:08:45 -0700 Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id AC87CE6D4C; Tue, 29 Jun 2004 09:07:06 +0100 (BST) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30843-14; Tue, 29 Jun 2004 09:07:06 +0100 (BST) Received: from oak.dgreaves.com (modem-3454.kawau.dialup.pol.co.uk [81.78.157.126]) by mail.ukfsn.org (Postfix) with ESMTP id BF4E5E6D3C; Tue, 29 Jun 2004 09:07:05 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.66]) by oak.dgreaves.com with esmtp (Exim 4.20) id 1BfDhj-0006jH-CY; Tue, 29 Jun 2004 09:10:59 +0100 Message-ID: <40E12382.7050805@dgreaves.com> Date: Tue, 29 Jun 2004 09:08:34 +0100 From: David Greaves User-Agent: Mozilla Thunderbird 0.6 (X11/20040528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Venkatesan, Ganesh" Cc: Anton Blanchard , netdev@oss.sgi.com, cramerj , "Ronciak, John" Subject: Re: e1000_clean_tx_ring References: <468F3FDA28AA87429AD807992E22D07E01967ADD@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01967ADD@orsmsx408> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: netdev FYI It hasn't helped with either of my problems; watchdog timeout or mtu 9000 malloc David Venkatesan, Ganesh wrote: >Anton: > >We will integrate this patch into the next release of our driver. > >Thanks, >ganesh > >------------------------------------------------- >Ganesh Venkatesan >Network/Storage Division, Hillsboro, OR > >-----Original Message----- >From: Anton Blanchard [mailto:anton@samba.org] >Sent: Thursday, June 24, 2004 4:23 PM >To: netdev@oss.sgi.com >Cc: cramerj; Ronciak, John; Venkatesan, Ganesh >Subject: e1000_clean_tx_ring > > >Hi, > >I was looking over the e1000 driver and noticed what I think is a bug >in e1000_clean_tx_ring. We wouldnt call pci_unmap_page on tx ring >entries that didnt have ->skb filled, eg zero copy packets. > >This is on latest 2.6 BK. > >Anton > >===== e1000_main.c 1.120 vs edited ===== >--- 1.120/drivers/net/e1000/e1000_main.c Sat Jun 19 10:00:00 2004 >+++ edited/e1000_main.c Thu Jun 24 02:16:42 2004 >@@ -1070,14 +1070,19 @@ > > for(i = 0; i < tx_ring->count; i++) { > buffer_info = &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); > >- dev_kfree_skb(buffer_info->skb); >+ buffer_info->dma = NULL; >+ } >+ >+ if (buffer_info->skb) { >+ >+ dev_kfree_skb_any(buffer_info->skb); > > buffer_info->skb = NULL; > } > > > > > > > From kuznet@ms2.inr.ac.ru Tue Jun 29 01:25:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 01:25:31 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T8PPgi031675 for ; Tue, 29 Jun 2004 01:25:28 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id MAA27026; Tue, 29 Jun 2004 12:22:52 +0400 Date: Tue, 29 Jun 2004 12:22:52 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040629082252.GA26866@ms2.inr.ac.ru> References: <20040628231439.GA3021@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040628231439.GA3021@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > The solution seems simple. We already have a connect(2) call for > NETLINK sockets. So why don't we check the connected address of > the destination socket against the address of the sender before > putting the packet on the queue? Do you mean the restriction sort of made in AF_UNIX SOCK_DGRAM: a connected socket receives messages only from its destination? I think this is safe. It was not done because netlink sockets were expected to listen for broadcasts, so that this kind of protection would be not useful and even harmful. But taking into account that inter-application communication is not used, only kernel sends broadcasts and applications talking to kernel will receive such broadcasts, because they are connected to kernel. The troube is that pid of kernel socket used to be 0, so that applications connected to kernel are not connected in technical sense. :-) Apparently, to implement this we have to add some kind of flag marking connected sockets. Alexey From herbert@gondor.apana.org.au Tue Jun 29 01:46:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 01:46:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5T8kcgi032402 for ; Tue, 29 Jun 2004 01:46: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 1BfEFa-0007H0-00; Tue, 29 Jun 2004 18:45:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BfEFU-0001gW-00; Tue, 29 Jun 2004 18:45:52 +1000 Date: Tue, 29 Jun 2004 18:45:52 +1000 To: Alexey Kuznetsov Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040629084552.GA6202@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629082252.GA26866@ms2.inr.ac.ru> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6408 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 Tue, Jun 29, 2004 at 12:22:52PM +0400, Alexey Kuznetsov wrote: > > Do you mean the restriction sort of made in AF_UNIX SOCK_DGRAM: > a connected socket receives messages only from its destination? Exactly. Another example would be UDP over IP. > It was not done because netlink sockets were expected to listen > for broadcasts, so that this kind of protection would be not useful > and even harmful. But taking into account that inter-application > communication is not used, only kernel sends broadcasts and applications > talking to kernel will receive such broadcasts, because they are connected > to kernel. I've had a look in the various NETLINK applications that I know of, including quagga/iproute/iptables and all the stuff that I wrote, none of them does a connect at all. So it should be harmless to introduce this new semantics. > The troube is that pid of kernel socket used to be 0, so that > applications connected to kernel are not connected in technical sense. :-) That's kind of a good thing since it means that existing applications are less likely to call connect(2) :) > Apparently, to implement this we have to add some kind of flag > marking connected sockets. Or we can set the disconnected pid to a negative value since POSIX requires pid_t to be signed. I see that you've reserved everything between -4096 and 0. So perhaps we can pick -1? 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 kuznet@ms2.inr.ac.ru Tue Jun 29 04:17:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 04:17:24 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TBH3gi008126 for ; Tue, 29 Jun 2004 04:17:04 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id PAA28550; Tue, 29 Jun 2004 15:14:33 +0400 Date: Tue, 29 Jun 2004 15:14:33 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040629111433.GA28463@ms2.inr.ac.ru> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629084552.GA6202@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > Or we can set the disconnected pid to a negative value since POSIX > requires pid_t to be signed. I see that you've reserved everything > between -4096 and 0. So perhaps we can pick -1? I think we can. Alexey From herbert@gondor.apana.org.au Tue Jun 29 04:19:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 04:19:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TBJKgi011485 for ; Tue, 29 Jun 2004 04:19: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 1BfGdI-0008Kt-00; Tue, 29 Jun 2004 21:18:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BfGdF-0005xF-00; Tue, 29 Jun 2004 21:18:33 +1000 Date: Tue, 29 Jun 2004 21:18:33 +1000 To: Alexey Kuznetsov Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040629111833.GA22880@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629111433.GA28463@ms2.inr.ac.ru> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6410 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 Tue, Jun 29, 2004 at 03:14:33PM +0400, Alexey Kuznetsov wrote: > > > Or we can set the disconnected pid to a negative value since POSIX > > requires pid_t to be signed. I see that you've reserved everything > > between -4096 and 0. So perhaps we can pick -1? > > I think we can. Great. I'll code it up 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 jt@bougret.hpl.hp.com Tue Jun 29 09:25:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 09:25:34 -0700 (PDT) Received: from phobos.hpl.hp.com (phobos.hpl.hp.com [192.6.19.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TGPWgi029164 for ; Tue, 29 Jun 2004 09:25:32 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by phobos.hpl.hp.com (8.9.3 (PHNE_29773)/HPL-PA Relay) with ESMTP id JAA07718; Tue, 29 Jun 2004 09:23:56 -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 JAA14208; Tue, 29 Jun 2004 09:23:56 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BfLOV-0001FG-00; Tue, 29 Jun 2004 09:23:39 -0700 Date: Tue, 29 Jun 2004 09:23:39 -0700 To: Linux kernel mailing list , netdev@oss.sgi.com Cc: Jeff Garzik , "David S. Miller" Subject: Updated Wireless Extension patches Message-ID: <20040629162339.GA4356@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-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 7) X-archive-position: 6411 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 Hi all, I've been working a bit more on my current set of Wireless Extension patches (WPA, Wireless-RtNetlink, ...). I've just updated them on my personal web page : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#wext The main change is that I'm now happy of the format of Wireless over RtNetlink, so it should be close to definitive. I've also split all the minor changes as a separate patch (WE-17), so it doesn't have to wait for WPA and Wireless-RtNetlink that still need a bit of work, and I plan to push this patch soon. You will also find patches for various drivers to take advantage of the new features. I would like to thank the various driver authors that sent me patches, suggestions and comments, and thank them for their patience. Have fun... Jean From davem@redhat.com Tue Jun 29 12:44:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 12:44:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TJiggi005713 for ; Tue, 29 Jun 2004 12:44:43 -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 i5TJiee1002693; Tue, 29 Jun 2004 15:44: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 i5TJie015123; Tue, 29 Jun 2004 15:44: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 i5TJiCHO017039; Tue, 29 Jun 2004 15:44:15 -0400 Date: Tue, 29 Jun 2004 12:44:18 -0700 From: "David S. Miller" To: "Angelo Dell'Aera" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP congestion control article Message-Id: <20040629124418.54bfe820.davem@redhat.com> In-Reply-To: <20040629203418.0a844a5b.buffer@antifork.org> References: <20040625123953.1d42b556.buffer@antifork.org> <20040625091158.2e84ed3a.davem@redhat.com> <20040629203418.0a844a5b.buffer@antifork.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: 6412 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 Tue, 29 Jun 2004 20:34:18 +0200 "Angelo Dell'Aera" wrote: > First of all I know not too much about BITCP but I think it's unsafe > to enable it by default... just like it's unsafe to enable by default > any kind of new congestion control algorithm. I disagree. In Stephen Hemminger and my own usage, BICTCP even improved performance in cases where we had mistakenly misconfigured our systems. That, frankly, is impressive. Because it deals with long-fat-pipe issues as well, was another reason we choose to enable it over westwood+. > Another thing. I think it's necessary to provide some mechanism for > enabling just one of these algorithms at a time. We do, you turn one on and another one off. :-) I discussed this with Stephen the other week. We came to the conclusion that enabling both algorithms at the same time is valid, and we should not put obstacles in the way to prevent people who wish to do this. It might even be beneficial in some situations. I agree with your analysis of Vegas, and that is why I did not enable it by default. It has it's own set of problems, although I like many aspects of it. From mcgrof@studorgs.rutgers.edu Tue Jun 29 12:58:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 12:58:46 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TJwSgi006311 for ; Tue, 29 Jun 2004 12:58:30 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 512F0F9D4D; Tue, 29 Jun 2004 15:21:01 -0400 (EDT) Date: Tue, 29 Jun 2004 15:21:01 -0400 To: Netdev Cc: prism54-devel@prism54.org Subject: Prism54 wpa update Message-ID: <20040629192101.GB14482@ruslug.rutgers.edu> Mail-Followup-To: Netdev , prism54-devel@prism54.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" 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: 6413 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 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'll keep my latest wpa work/patch at the following URL: http://prism54.org/~mcgrof/prism54-wpa.diff I've nuked module params and am relying on private ioctls now since, * we already have a [s|g]et_wpa priv iotcl, and * in preperation for the WPA patch for Wireless Extensions. I'll work on wpa ie scans tonight and try to fix mgt for handling traps in extended mode. This is not related to wpa, but I also made the firmware load at probe time. I turned the radio off at probe after firmware load time too since the device is not technically up yet. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA4cEdat1JN+IKUl4RAr7HAKCWl78xE45gcKcWFUJo0QCLQb2RoACfYOz3 Uy06CXuRohax/OYfmDrJmwE= =dDHU -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From ahu@outpost.ds9a.nl Tue Jun 29 13:10:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 13:10:46 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TKAXgi006937 for ; Tue, 29 Jun 2004 13:10:34 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8F0F13FCC; Tue, 29 Jun 2004 21:35:07 +0200 (CEST) Date: Tue, 29 Jun 2004 21:35:07 +0200 From: bert hubert To: netdev@oss.sgi.com Subject: [debi.janos@freemail.hu: Re: 2.6.7-mm1 - 2.6.7-mm4 weird http behavior] Message-ID: <20040629193507.GA10872@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 6414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Netdev people, I think this thread on lkml is worthy of your attention, this is one message in it. The summary is that recent mm kernels cannot connect to some servers, and that the sysctl below solves it. ----- Forwarded message from Debi Janos ----- Date: Tue, 29 Jun 2004 20:47:57 +0200 (CEST) From: Debi Janos Subject: Re: 2.6.7-mm1 - 2.6.7-mm4 weird http behavior To: bert hubert Cc: linux-kernel@vger.kernel.org bert hubert ?rta: > On Tue, Jun 29, 2004 at 08:04:46PM +0200, Debi Janos wrote: > > bert hubert ?rta: > Suggestions: > 1) turn off timestamps (echo 0 > /proc/sys/net/ipv4/tcp_timestamps) > 2) set your MTU to 1000 or so (ifconfig eth0 mtu 1000) > > And try again. > > Interesting case! problem workarounded: sysctl -w net.ipv4.tcp_moderate_rcvbuf=0 sysctl -w net.ipv4.tcp_default_win_scale=0 Thanks. ----- End forwarded message ----- -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From garzik@havoc.gtf.org Tue Jun 29 13:27:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 13:27:31 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TKRJgi007586 for ; Tue, 29 Jun 2004 13:27:19 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id E0C7F75FB; Tue, 29 Jun 2004 15:45:25 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5TJjPAb001502; Tue, 29 Jun 2004 15:45:25 -0400 Date: Tue, 29 Jun 2004 15:45:25 -0400 From: Jeff Garzik To: jt@hpl.hp.com Cc: Linux kernel mailing list , netdev@oss.sgi.com, "David S. Miller" Subject: Re: Updated Wireless Extension patches Message-ID: <20040629194525.GF23191@havoc.gtf.org> References: <20040629162339.GA4356@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629162339.GA4356@bougret.hpl.hp.com> User-Agent: Mutt/1.4.1i X-archive-position: 6415 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 On Tue, Jun 29, 2004 at 09:23:39AM -0700, Jean Tourrilhes wrote: > Hi all, > > I've been working a bit more on my current set of Wireless > Extension patches (WPA, Wireless-RtNetlink, ...). I've just updated > them on my personal web page : > http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#wext > > The main change is that I'm now happy of the format of > Wireless over RtNetlink, so it should be close to definitive. I've > also split all the minor changes as a separate patch (WE-17), so it > doesn't have to wait for WPA and Wireless-RtNetlink that still need a > bit of work, and I plan to push this patch soon. > You will also find patches for various drivers to take > advantage of the new features. I would like to thank the various > driver authors that sent me patches, suggestions and comments, and > thank them for their patience. Regardless of our recent discussions, I do want to emphasize that I wish to maintain the current WE, and its backwards compatibility, for the current 2.6.x stable series at the very least. So please don't be discouraged from submitting WE patches... Jeff P.S. do associated userland wireless-tools patches exist to make use of netlink? i.e. how have you been testing it? From akpm@osdl.org Tue Jun 29 13:38:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 13:38:37 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TKcWgi008314 for ; Tue, 29 Jun 2004 13:38:33 -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 i5TKcQG17447 for ; Tue, 29 Jun 2004 13:38:26 -0700 Date: Tue, 29 Jun 2004 13:37:30 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 2979] New: kernel BUG at net/appletalk/ddp.c Message-Id: <20040629133730.4595189b.akpm@osdl.org> 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: 6416 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 Begin forwarded message: Date: Tue, 29 Jun 2004 03:43:31 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 2979] New: kernel BUG at net/appletalk/ddp.c http://bugme.osdl.org/show_bug.cgi?id=2979 Summary: kernel BUG at net/appletalk/ddp.c Kernel Version: 2.6.7 Status: NEW Severity: high Owner: acme@conectiva.com.br Submitter: philipp@linbit.com Distribution: Debian 3.0 (Woody) Hardware Environment: Dell PowerEdge 2650 Dual CPU Software Environment: Netatalk 1.63 Steps to reproduce: Random Crashes in ~ 1 Week Intervals Problem Description: We have random crashes at a school with a mixed PC/Mac Network. We have about 300 Mac PC's and 200 PC's. The crashes happen in Intervals of about 1 Weeks. We are not able to reproduce the crashes. We are now using vanilla kernel 2.6.7 (SMP, Highmem). We had these crashes with kernel 2.4.25 (SMP, Highmem; UP, Highmem)also. See attached Oopses. I don't know if the Oopses are directly related but the frequency of their occurence suggests so. It seems to that something on the network generates bad appletalk traffic 2.6.7 SMP, Highmem: ------------------< cut <------------------ kernel BUG at net/appletalk/ddp.c:1018! invalid operand: 0000 [#1] SMP Modules linked in: snd_pcm_oss snd_pcm snd_page_alloc snd_timer snd_mixer_oss snd soundcore appletalk psnap llc parport_pc lp parport ipv6 tg3 psmouse CPU: 2 EIP: 0060:[] Not tainted EFLAGS: 00010206 (2.6.7sv-p3-smp-highmem) EIP is at atalk_sum_skb+0x1eb/0x200 [appletalk] eax: 00000000 ebx: 00000011 ecx: 00000000 edx: cf804680 esi: cf804680 edi: 00000006 ebp: f770e000 esp: f7f87e18 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=f7f86000 task=f7f9eb50) Stack: c1bde760 cf804680 00000015 f770e000 cf804680 00000000 00000015 f8c0d5e6 cf804680 00000015 00000017 000065ef f8c0de9f cf804680 0000001b cf804680 cf804680 f7bce8a8 c0636e00 cf804680 e41b4680 0000003a dcb9d500 cf804680 Call Trace: [] atalk_checksum+0x16/0x2c [appletalk] [] atalk_rcv+0xf3/0x27c [appletalk] [] snap_rcv+0x53/0x8c [psnap] [] llc_rcv+0x14b/0x214 [llc] [] netif_receive_skb+0x191/0x1c8 [] tg3_rx+0x29a/0x3b8 [tg3] [] tg3_poll+0x9a/0x12c [tg3] [] net_rx_action+0x82/0x11c [] __do_softirq+0x4e/0xa4 [] do_softirq+0x28/0x30 [] do_IRQ+0x113/0x124 [] common_interrupt+0x18/0x20 [] default_idle+0x2c/0x34 [] cpu_idle+0x30/0x40 [] start_secondary+0x72/0x74 [] printk+0x11d/0x134 [] print_cpu_info+0xa3/0xbc [] do_boot_cpu+0x112/0x178 Code: 0f 0b fa 03 9f fa c0 f8 8b 44 24 2c 5b 5e 5f 5d 83 c4 0c c3 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing ------------------< cut <------------------ 2.4.25 SMP, Highmem ------------------< cut <------------------ CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00000086 eax: f3722710 ebx: f3722710 ecx: 00000001 edx: 00000001 esi: f499aa00 edi: f3722710 ebp: c0457ea0 esp: c0457e84 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0457000) Stack: f3722710 f499aa00 f8bfda20 f7536b40 c03137d7 00000282 00000001 f8bfdaa0 c03051a3 f499aa00 c3b9df20 c030474d f499aa00 c3b9df24 c030581f e45ea3a0 c3b9df24 f8bfda20 f8bf80c8 e45ea3a0 f8bfda60 0000000f f8bf84eb c3b9df20 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 7e f9 e9 77 ef ff ff 80 3d 80 ec 48 c0 00 f3 90 7e f5 e9 94 >>EIP; c0118665 <.text.lock.sched+8f/1da> <===== >>eax; f3722710 <_end+332177b4/386960a4> >>ebx; f3722710 <_end+332177b4/386960a4> >>esi; f499aa00 <_end+3448faa4/386960a4> >>edi; f3722710 <_end+332177b4/386960a4> >>ebp; c0457ea0 >>esp; c0457e84 Trace; f8bfda20 <[appletalk]resolved+0/0> Trace; c03137d7 Trace; f8bfdaa0 <[appletalk]proxies+0/40> Trace; c03051a3 Trace; c030474d Trace; c030581f <__kfree_skb+77/140> Trace; f8bfda20 <[appletalk]resolved+0/0> Trace; f8bf80c8 <[appletalk]__aarp_expire+68/7c> Trace; f8bfda60 <[appletalk]unresolved+0/40> Trace; f8bf84eb <[appletalk]__aarp_kick+23/40> Trace; f8bfda60 <[appletalk]unresolved+0/40> Trace; f8bf857c <[appletalk]aarp_expire_timeout+44/c8> Trace; f8bfda60 <[appletalk]unresolved+0/40> Trace; f8bfda20 <[appletalk]resolved+0/0> Trace; f8bf8538 <[appletalk]aarp_expire_timeout+0/c8> Trace; c01225ef Trace; c011f130 Trace; c011f013 Trace; c011ed9d Trace; c010a37b Trace; c0106d60 Trace; c0106d60 Trace; c0106d60 Trace; c0106d60 Trace; c0106d8c Trace; c0106df2 Trace; c0105000 <_stext+0/0> Trace; c010504f Code; c0118665 <.text.lock.sched+8f/1da> 00000000 <_EIP>: Code; c0118665 <.text.lock.sched+8f/1da> <===== 0: 7e f9 jle fffffffb <_EIP+0xfffffffb> c0118660 <.text.lock.sched+8a/1da> <===== Code; c0118667 <.text.lock.sched+91/1da> 2: e9 77 ef ff ff jmp ffffef7e <_EIP+0xffffef7e> c01175e3 <__wake_up+1b/c4> Code; c011866c <.text.lock.sched+96/1da> 7: 80 3d 80 ec 48 c0 00 cmpb $0x0,0xc048ec80 Code; c0118673 <.text.lock.sched+9d/1da> e: f3 90 repz nop Code; c0118675 <.text.lock.sched+9f/1da> 10: 7e f5 jle 7 <_EIP+0x7> c011866c <.text.lock.sched+96/1da> Code; c0118677 <.text.lock.sched+a1/1da> 12: e9 94 00 00 00 jmp ab <_EIP+0xab> c0118710 <.text.lock.sched+13a/1da> ------------------< cut <------------------ 2.4.25 UP, Highmem: ------------------< cut <------------------ Unable to handle kernel NULL pointer dereference at virtual address 00000000 c0113e94 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: d38a4530 ebx: 00000000 ecx: 00000001 edx: 00000001 esi: d38a4530 edi: 00000001 ebp: c04a9ec4 esp: c04a9eac ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c04a9000) Stack: d38a4530 d3542440 f8bfba8c f7d13600 00000286 00000001 f8bfbb0c c035d89b d3542440 c2c4c920 c035cf8c d3542440 c2c4c924 c035ddfd f67f86a0 c2c4c924 f8bfba8c f8bf70be f67f86a0 f8bfbacc 0000000c f8bf74db c2c4c920 f8bfbacc Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 03 0f 18 00 83 c6 04 89 75 f4 39 f3 74 69 8b 4b fc 8b 01 >>EIP; c0113e94 <__wake_up+20/a4> <===== >>eax; d38a4530 <_end+13381d94/3867e864> >>esi; d38a4530 <_end+13381d94/3867e864> >>ebp; c04a9ec4 >>esp; c04a9eac Trace; f8bfba8c <[appletalk].bss.start+c/40> Trace; f8bfbb0c <[appletalk]proxies+c/40> Trace; c035d89b Trace; c035cf8c Trace; c035ddfd <__kfree_skb+69/130> Trace; f8bfba8c <[appletalk].bss.start+c/40> Trace; f8bf70be <[appletalk]__aarp_expire+5e/70> Trace; f8bfbacc <[appletalk]unresolved+c/40> Trace; f8bf74db <[appletalk]__aarp_kick+23/40> Trace; f8bfbacc <[appletalk]unresolved+c/40> Trace; f8bf7552 <[appletalk]aarp_expire_timeout+2a/94> Trace; f8bfbacc <[appletalk]unresolved+c/40> Trace; f8bfba8c <[appletalk].bss.start+c/40> Trace; f8bf7528 <[appletalk]aarp_expire_timeout+0/94> Trace; c011d5ec Trace; c011a612 Trace; c011a556 Trace; c011a37a Trace; c0109a32 Trace; c0106ce0 Trace; c0106ce0 Trace; c0106ce0 Trace; c0106ce0 Trace; c0106d03 Trace; c0106d69 Trace; c0105000 <_stext+0/0> Trace; c0105027 Code; c0113e94 <__wake_up+20/a4> 00000000 <_EIP>: Code; c0113e94 <__wake_up+20/a4> <===== 0: 8b 03 mov (%ebx),%eax <===== Code; c0113e96 <__wake_up+22/a4> 2: 0f 18 00 prefetchnta (%eax) Code; c0113e99 <__wake_up+25/a4> 5: 83 c6 04 add $0x4,%esi Code; c0113e9c <__wake_up+28/a4> 8: 89 75 f4 mov %esi,0xfffffff4(%ebp) Code; c0113e9f <__wake_up+2b/a4> b: 39 f3 cmp %esi,%ebx Code; c0113ea1 <__wake_up+2d/a4> d: 74 69 je 78 <_EIP+0x78> c0113f0c <__wake_up+98/a4> Code; c0113ea3 <__wake_up+2f/a4> f: 8b 4b fc mov 0xfffffffc(%ebx),%ecx Code; c0113ea6 <__wake_up+32/a4> 12: 8b 01 mov (%ecx),%eax <0>Kernel panic: Aiee, killing interrupt handler! ------------------< cut <------------------ ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From shemminger@osdl.org Tue Jun 29 14:00:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:00:37 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TL0Ygi009144 for ; Tue, 29 Jun 2004 14:00:35 -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 i5TL0MG22005; Tue, 29 Jun 2004 14:00:22 -0700 Date: Tue, 29 Jun 2004 14:00:21 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (4/4) packet scheduler -- use get_jiffies_64 Message-Id: <20040629140021.367695ff@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: 6420 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 The packet scheduler simulates 64 bit jiffies on 32 bit platforms by running a timer keeping a mark and and offset. Since there is no locking and this is racy and doesn't handle jiffie wrap real well. We can use get_jiffies_64 on 2.6 do get what is needed. The downside is the overhead of a function call, and a cache miss in get_jiffies_64. Signed-off-by: Stephen Hemminger diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-06-29 11:33:37 -07:00 +++ b/include/net/pkt_sched.h 2004-06-29 11:33:37 -07:00 @@ -231,20 +231,7 @@ #define PSCHED_JSCALE 10 #endif -#if BITS_PER_LONG <= 32 - -#define PSCHED_WATCHER unsigned long - -extern PSCHED_WATCHER psched_time_mark; - -#define PSCHED_GET_TIME(stamp) ((stamp) = psched_time_base + (((unsigned long)(jiffies-psched_time_mark))<>PSCHED_JSCALE) #define PSCHED_JIFFIE2US(delay) ((delay)<; Tue, 29 Jun 2004 14:00: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 i5TL0EG21989; Tue, 29 Jun 2004 14:00:14 -0700 Date: Tue, 29 Jun 2004 14:00:14 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/4) packet scheduler exports Message-Id: <20040629140014.1aba3719@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: 6417 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 The packet scheduling code has some ugly define's which were to deal with configuration possibilities and the old style module exports. With the current 2.6 method, this is unnecessary. Signed-off-by: Stephen Hemminger diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-06-29 11:32:21 -07:00 +++ b/include/net/pkt_sched.h 2004-06-29 11:32:21 -07:00 @@ -210,12 +210,8 @@ #define PSCHED_US2JIFFIE(usecs) (((usecs)+(1000000/HZ-1))/(1000000/HZ)) #define PSCHED_JIFFIE2US(delay) ((delay)*(1000000/HZ)) -#define PSCHED_EXPORTLIST EXPORT_SYMBOL(psched_tod_diff); - #else /* PSCHED_CLOCK_SOURCE != PSCHED_GETTIMEOFDAY */ -#define PSCHED_EXPORTLIST PSCHED_EXPORTLIST_1 PSCHED_EXPORTLIST_2 - typedef u64 psched_time_t; typedef long psched_tdiff_t; @@ -235,8 +231,6 @@ #define PSCHED_JSCALE 10 #endif -#define PSCHED_EXPORTLIST_2 - #if BITS_PER_LONG <= 32 #define PSCHED_WATCHER unsigned long @@ -245,15 +239,10 @@ #define PSCHED_GET_TIME(stamp) ((stamp) = psched_time_base + (((unsigned long)(jiffies-psched_time_mark))<>PSCHED_JSCALE) @@ -264,9 +253,6 @@ extern psched_tdiff_t psched_clock_per_hz; extern int psched_clock_scale; -#define PSCHED_EXPORTLIST_2 EXPORT_SYMBOL(psched_clock_per_hz); \ - EXPORT_SYMBOL(psched_clock_scale); - #define PSCHED_US2JIFFIE(delay) (((delay)+psched_clock_per_hz-1)/psched_clock_per_hz) #define PSCHED_JIFFIE2US(delay) ((delay)*psched_clock_per_hz) @@ -278,8 +264,6 @@ (stamp) = __cur>>psched_clock_scale; \ }) -#define PSCHED_EXPORTLIST_1 - #elif defined (__alpha__) #define PSCHED_WATCHER u32 @@ -293,9 +277,6 @@ psched_time_mark = __res; \ (stamp) = (psched_time_base + __res)>>psched_clock_scale; \ }) - -#define PSCHED_EXPORTLIST_1 EXPORT_SYMBOL(psched_time_base); \ - EXPORT_SYMBOL(psched_time_mark); #else diff -Nru a/net/sched/sch_api.c b/net/sched/sch_api.c --- a/net/sched/sch_api.c 2004-06-29 11:32:21 -07:00 +++ b/net/sched/sch_api.c 2004-06-29 11:32:21 -07:00 @@ -1098,6 +1098,7 @@ delta = bound; return delta; } +EXPORT_SYMBOL(psched_tod_diff); #endif psched_time_t psched_time_base; @@ -1105,10 +1106,14 @@ #if PSCHED_CLOCK_SOURCE == PSCHED_CPU psched_tdiff_t psched_clock_per_hz; int psched_clock_scale; +EXPORT_SYMBOL(psched_clock_per_hz); +EXPORT_SYMBOL(psched_clock_scale); #endif #ifdef PSCHED_WATCHER PSCHED_WATCHER psched_time_mark; +EXPORT_SYMBOL(psched_time_mark); +EXPORT_SYMBOL(psched_time_base); static void psched_tick(unsigned long); @@ -1214,4 +1219,3 @@ EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); EXPORT_SYMBOL(unregister_qdisc); -PSCHED_EXPORTLIST; From shemminger@osdl.org Tue Jun 29 14:00:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:00:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TL0Tgi009135 for ; Tue, 29 Jun 2004 14:00:30 -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 i5TL0HG21993; Tue, 29 Jun 2004 14:00:17 -0700 Date: Tue, 29 Jun 2004 14:00:16 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/4) packet scheduler bad TDIFF_SAFE in csz Message-Id: <20040629140016.4afeb36b@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: 6418 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 This code in the csz scheduler, is just plain broken. The TDIFF_SAFE effectively expands to: unsigned long delay = now - q->t_c; if (delay > 0) { delay = 0; goto do_reset; } if (delay >> q->delta_log) So delay is always 0! I assume that what was originally intended is the to keep delay bounded to 1<delta_log. Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_csz.c b/net/sched/sch_csz.c --- a/net/sched/sch_csz.c 2004-06-29 11:32:40 -07:00 +++ b/net/sched/sch_csz.c 2004-06-29 11:32:40 -07:00 @@ -378,10 +378,8 @@ unsigned long R_c; PSCHED_GET_TIME(now); - delay = PSCHED_TDIFF_SAFE(now, q->t_c, 0, goto do_reset); - + delay = PSCHED_TDIFF(now, q->t_c); if (delay>>q->delta_log) { -do_reset: /* Delta is too large. It is possible if MTU/BW > 1<delta_log (i.e. configuration error) or because of hardware From shemminger@osdl.org Tue Jun 29 14:00:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:00:35 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TL0Wgi009139 for ; Tue, 29 Jun 2004 14:00: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 i5TL0JG21997; Tue, 29 Jun 2004 14:00:19 -0700 Date: Tue, 29 Jun 2004 14:00:19 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (3/4) packet scheduler - eliminate guard from TDIFF_SAFE Message-Id: <20040629140019.2efbf6f6@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: 6419 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 The last argument in the PSCHED_TDIFF_SAFE is no longer used; only usage eliminated by previous patch. It gets rid of a bad macro usage. Also, can use the standard min_t macro which also eliminates the macro problem of double evaluation of bound. Signed-off-by: Stephen Hemminger diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-06-29 11:48:30 -07:00 +++ b/include/net/pkt_sched.h 2004-06-29 11:48:30 -07:00 @@ -308,13 +308,13 @@ extern int psched_tod_diff(int delta_sec, int bound); -#define PSCHED_TDIFF_SAFE(tv1, tv2, bound, guard) \ +#define PSCHED_TDIFF_SAFE(tv1, tv2, bound) \ ({ \ int __delta_sec = (tv1).tv_sec - (tv2).tv_sec; \ int __delta = (tv1).tv_usec - (tv2).tv_usec; \ switch (__delta_sec) { \ default: \ - __delta = psched_tod_diff(__delta_sec, bound); guard; break; \ + __delta = psched_tod_diff(__delta_sec, bound); break; \ case 2: \ __delta += 1000000; \ case 1: \ @@ -355,12 +355,8 @@ #else #define PSCHED_TDIFF(tv1, tv2) (long)((tv1) - (tv2)) -#define PSCHED_TDIFF_SAFE(tv1, tv2, bound, guard) \ -({ \ - long long __delta = (tv1) - (tv2); \ - if ( __delta > (long long)(bound)) { __delta = (bound); guard; } \ - __delta; \ -}) +#define PSCHED_TDIFF_SAFE(tv1, tv2, bound) \ + min_t(long long, (tv1) - (tv2), bound) #define PSCHED_TLESS(tv1, tv2) ((tv1) < (tv2)) diff -Nru a/net/sched/police.c b/net/sched/police.c --- a/net/sched/police.c 2004-06-29 11:48:30 -07:00 +++ b/net/sched/police.c 2004-06-29 11:48:30 -07:00 @@ -321,7 +321,7 @@ PSCHED_GET_TIME(now); - toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst, (void)0); + toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst); if (p->P_tab) { ptoks = toks + p->ptoks; @@ -523,7 +523,7 @@ PSCHED_GET_TIME(now); - toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst, (void)0); + toks = PSCHED_TDIFF_SAFE(now, p->t_c, p->burst); if (p->P_tab) { ptoks = toks + p->ptoks; diff -Nru a/net/sched/sch_gred.c b/net/sched/sch_gred.c --- a/net/sched/sch_gred.c 2004-06-29 11:48:30 -07:00 +++ b/net/sched/sch_gred.c 2004-06-29 11:48:30 -07:00 @@ -155,7 +155,7 @@ if (!PSCHED_IS_PASTPERFECT(q->qidlestart)) { long us_idle; PSCHED_GET_TIME(now); - us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, (void)0); + us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max); PSCHED_SET_PASTPERFECT(q->qidlestart); q->qave >>= q->Stab[(us_idle>>q->Scell_log)&0xFF]; @@ -551,7 +551,7 @@ long idle; psched_time_t now; PSCHED_GET_TIME(now); - idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, (void)0); + idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max); qave = q->qave >> q->Stab[(idle>>q->Scell_log)&0xFF]; dst->qave = qave >> q->Wlog; diff -Nru a/net/sched/sch_htb.c b/net/sched/sch_htb.c --- a/net/sched/sch_htb.c 2004-06-29 11:48:30 -07:00 +++ b/net/sched/sch_htb.c 2004-06-29 11:48:30 -07:00 @@ -367,7 +367,7 @@ struct list_head *l; list_for_each (l,q->hash+i) { struct htb_class *cl = list_entry(l,struct htb_class,hlist); - long diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, (void)0); + long diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer); printk(KERN_DEBUG "htb*c%x m=%d t=%ld c=%ld pq=%lu df=%ld ql=%d " "pa=%x f:", cl->classid,cl->cmode,cl->tokens,cl->ctokens, @@ -807,7 +807,7 @@ while (cl) { HTB_CHCL(cl); - diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, (void)0); + diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer); #ifdef HTB_DEBUG if (diff > cl->mbuffer || diff < 0 || PSCHED_TLESS(q->now, cl->t_c)) { if (net_ratelimit()) @@ -878,7 +878,7 @@ return cl->pq_key - q->jiffies; } htb_safe_rb_erase(p,q->wait_pq+level); - diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer, (void)0); + diff = PSCHED_TDIFF_SAFE(q->now, cl->t_c, (u32)cl->mbuffer); #ifdef HTB_DEBUG if (diff > cl->mbuffer || diff < 0 || PSCHED_TLESS(q->now, cl->t_c)) { if (net_ratelimit()) diff -Nru a/net/sched/sch_red.c b/net/sched/sch_red.c --- a/net/sched/sch_red.c 2004-06-29 11:48:30 -07:00 +++ b/net/sched/sch_red.c 2004-06-29 11:48:30 -07:00 @@ -189,7 +189,7 @@ int shift; PSCHED_GET_TIME(now); - us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max, (void)0); + us_idle = PSCHED_TDIFF_SAFE(now, q->qidlestart, q->Scell_max); PSCHED_SET_PASTPERFECT(q->qidlestart); /* diff -Nru a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c --- a/net/sched/sch_tbf.c 2004-06-29 11:48:30 -07:00 +++ b/net/sched/sch_tbf.c 2004-06-29 11:48:30 -07:00 @@ -207,7 +207,7 @@ PSCHED_GET_TIME(now); - toks = PSCHED_TDIFF_SAFE(now, q->t_c, q->buffer, (void)0); + toks = PSCHED_TDIFF_SAFE(now, q->t_c, q->buffer); if (q->P_tab) { ptoks = toks + q->ptokens; From garzik@havoc.gtf.org Tue Jun 29 14:02:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:02:22 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TL29gi009796 for ; Tue, 29 Jun 2004 14:02:10 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 868A3760A; Tue, 29 Jun 2004 16:22:15 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i5TKMAPD005380; Tue, 29 Jun 2004 16:22:10 -0400 Date: Tue, 29 Jun 2004 16:22:10 -0400 From: Jeff Garzik To: Netdev , prism54-devel@prism54.org Subject: Re: Prism54 wpa update Message-ID: <20040629202210.GK23191@havoc.gtf.org> References: <20040629192101.GB14482@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629192101.GB14482@ruslug.rutgers.edu> User-Agent: Mutt/1.4.1i X-archive-position: 6421 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 On Tue, Jun 29, 2004 at 03:21:01PM -0400, Luis R. Rodriguez wrote: > > I'll keep my latest wpa work/patch at the following URL: > > http://prism54.org/~mcgrof/prism54-wpa.diff > > I've nuked module params and am relying on private ioctls now since, > > * we already have a [s|g]et_wpa priv iotcl, and > * in preperation for the WPA patch for Wireless Extensions. > > I'll work on wpa ie scans tonight and try to fix mgt for > handling traps in extended mode. This is not related to wpa, but > I also made the firmware load at probe time. I turned the radio > off at probe after firmware load time too since the device is > not technically up yet. Patch seems sane, though I vaguely recall xchg() not being atomic on all platforms (such as i386?). Maybe I'm wrong, an expert should speak up :) I also worry that the following is a race, but I have not traced the code to verify or discount my guess: + u32 mlme, authen, dot1x, filter, wep; + + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return 0; down_write(&priv->mib_sem); From jt@bougret.hpl.hp.com Tue Jun 29 14:08:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:08:05 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TL82gi010926 for ; Tue, 29 Jun 2004 14:08:02 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id A284C40D55B; Tue, 29 Jun 2004 14:08:01 -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 OAA23925; Tue, 29 Jun 2004 14:08:18 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BfPQF-0003Ax-00; Tue, 29 Jun 2004 13:41:43 -0700 Date: Tue, 29 Jun 2004 13:41:43 -0700 To: Jeff Garzik Cc: Linux kernel mailing list , netdev@oss.sgi.com, "David S. Miller" Subject: Re: Updated Wireless Extension patches Message-ID: <20040629204143.GA11782@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040629162339.GA4356@bougret.hpl.hp.com> <20040629194525.GF23191@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629194525.GF23191@havoc.gtf.org> 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: 6422 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 On Tue, Jun 29, 2004 at 03:45:25PM -0400, Jeff Garzik wrote: > > Regardless of our recent discussions, I do want to emphasize that I wish > to maintain the current WE, and its backwards compatibility, for the > current 2.6.x stable series at the very least. > > So please don't be discouraged from submitting WE patches... No problem Jeff ;-) Because of my wife, I have learned to compromise (I just wish she had learned that as well). I already told you that the actual delivery mechanism to the driver doesn't matter to me, what matter to me is the vocabulary and gramar of the API. And also I want to satisfy the need of both driver authors and userspace. So, we are aiming for the same goal, just having slightly different methods. I plan to submit WE-17 to you somewhat soon, because Jouni needs it, and I've postponed it far too much. There is actually one change in WE-17 that you should appreciate. WPA and RtNetlink will go when they are ready, for WPA it depends on Jouni, for RtNetlink on me. > Jeff > > > P.S. do associated userland wireless-tools patches exist to make use of > netlink? i.e. how have you been testing it? Good catch ;-) There are some advantage to RtNetlink. Unfortunately, simplicity is not one. Dealing with RtNetlink is a lot of work compared to ioctl, as you may discover if you migrate your API to it. I have a pretty simple test app. I'm working on a version of iwlib that would go through RtNetlink, that would enable the full Wireless Tools to use RtNetlink. I'll try to release that soon. Have fun... Jean From davem@redhat.com Tue Jun 29 14:32:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:32:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TLWUgi011737 for ; Tue, 29 Jun 2004 14:32:30 -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 i5TLWMe1029499; Tue, 29 Jun 2004 17:32:22 -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 i5TLWM018911; Tue, 29 Jun 2004 17:32: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 i5TLVufZ020167; Tue, 29 Jun 2004 17:31:57 -0400 Date: Tue, 29 Jun 2004 14:32:02 -0700 From: "David S. Miller" To: Dmitry Torokhov Cc: netdev@oss.sgi.com, jamal@znyx.com Subject: Re: [PATCH] sch_prio - fix compile warning + some logic rearrangement in enqueue Message-Id: <20040629143202.3ae7093a.davem@redhat.com> In-Reply-To: <200406290106.38304.dtor_core@ameritech.net> References: <200406290106.38304.dtor_core@ameritech.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: 6423 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 Tue, 29 Jun 2004 01:06:36 -0500 Dmitry Torokhov wrote: > When CONFIG_NET_CLS_ACT is not set 'result' variable in prio_classify is > unused. Also I was looking over the rest of the module and had hard time > understanding the logic in prio_enqueue - I rearranged it a bit for better > readability. Plus there are some formatting changes. Looks good to me, applied. Thanks Dmitry. From davem@redhat.com Tue Jun 29 14:34:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:34:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TLYAgi012067 for ; Tue, 29 Jun 2004 14:34:10 -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 i5TLY7e1029771; Tue, 29 Jun 2004 17:34:07 -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 i5TLY7019253; Tue, 29 Jun 2004 17:34:07 -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 i5TLXgOe020991; Tue, 29 Jun 2004 17:33:42 -0400 Date: Tue, 29 Jun 2004 14:33:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) packet scheduler exports Message-Id: <20040629143347.510a1531.davem@redhat.com> In-Reply-To: <20040629140014.1aba3719@dell_ss3.pdx.osdl.net> References: <20040629140014.1aba3719@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: 6424 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 Tue, 29 Jun 2004 14:00:14 -0700 Stephen Hemminger wrote: > The packet scheduling code has some ugly define's which were to deal with > configuration possibilities and the old style module exports. With the current > 2.6 method, this is unnecessary. > > Signed-off-by: Stephen Hemminger Applied. From davem@redhat.com Tue Jun 29 14:45:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:45:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TLjUgi012656 for ; Tue, 29 Jun 2004 14:45:30 -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 i5TLjQe1032168; Tue, 29 Jun 2004 17:45:26 -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 i5TLjQ022654; Tue, 29 Jun 2004 17:45: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 i5TLj1K7027124; Tue, 29 Jun 2004 17:45:01 -0400 Date: Tue, 29 Jun 2004 14:45:06 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) packet scheduler bad TDIFF_SAFE in csz Message-Id: <20040629144506.0649d217.davem@redhat.com> In-Reply-To: <20040629140016.4afeb36b@dell_ss3.pdx.osdl.net> References: <20040629140016.4afeb36b@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: 6425 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 Tue, 29 Jun 2004 14:00:16 -0700 Stephen Hemminger wrote: > This code in the csz scheduler, is just plain broken. The TDIFF_SAFE > effectively expands to: > unsigned long delay = now - q->t_c; > if (delay > 0) { > delay = 0; > goto do_reset; > } > if (delay >> q->delta_log) > > So delay is always 0! I assume that what was originally intended > is the to keep delay bounded to 1<delta_log. This bug has been there since day one, wow. Good spotting, applied. From davem@redhat.com Tue Jun 29 14:46:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:46:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TLkjgi012846 for ; Tue, 29 Jun 2004 14:46:45 -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 i5TLkhe1032445; Tue, 29 Jun 2004 17:46:43 -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 i5TLkh022870; Tue, 29 Jun 2004 17:46:43 -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 i5TLkHiN027691; Tue, 29 Jun 2004 17:46:18 -0400 Date: Tue, 29 Jun 2004 14:46:22 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (3/4) packet scheduler - eliminate guard from TDIFF_SAFE Message-Id: <20040629144622.36108944.davem@redhat.com> In-Reply-To: <20040629140019.2efbf6f6@dell_ss3.pdx.osdl.net> References: <20040629140019.2efbf6f6@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: 6426 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 Tue, 29 Jun 2004 14:00:19 -0700 Stephen Hemminger wrote: > The last argument in the PSCHED_TDIFF_SAFE is no longer used; > only usage eliminated by previous patch. It gets rid of a bad macro > usage. Yes, good cleanup after the csz bugfix. Applied, thanks Stephen. From davem@redhat.com Tue Jun 29 14:47:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:47:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TLlCgi013081 for ; Tue, 29 Jun 2004 14:47: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 i5TLlAe1032564; Tue, 29 Jun 2004 17:47: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 i5TLl9022974; Tue, 29 Jun 2004 17:47: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 i5TLkidW027815; Tue, 29 Jun 2004 17:46:44 -0400 Date: Tue, 29 Jun 2004 14:46:49 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) packet scheduler -- use get_jiffies_64 Message-Id: <20040629144649.1d0b5723.davem@redhat.com> In-Reply-To: <20040629140021.367695ff@dell_ss3.pdx.osdl.net> References: <20040629140021.367695ff@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: 6427 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 Tue, 29 Jun 2004 14:00:21 -0700 Stephen Hemminger wrote: > The packet scheduler simulates 64 bit jiffies on 32 bit platforms by running > a timer keeping a mark and and offset. Since there is no locking and this is > racy and doesn't handle jiffie wrap real well. > > We can use get_jiffies_64 on 2.6 do get what is needed. > The downside is the overhead of a function call, and a cache miss in get_jiffies_64. Looks great, applied. From davem@redhat.com Tue Jun 29 14:50:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 14:50:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TLoigi013926 for ; Tue, 29 Jun 2004 14:50:45 -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 i5TLoae1000719; Tue, 29 Jun 2004 17:50: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 i5TLoa023831; Tue, 29 Jun 2004 17:50: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 i5TLoA3V029343; Tue, 29 Jun 2004 17:50:11 -0400 Date: Tue, 29 Jun 2004 14:50:15 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: dtor_core@ameritech.net, netdev@oss.sgi.com Subject: Re: [PATCH] sch_prio - fix compile warning + some logic rearrangement in enqueue Message-Id: <20040629145015.41ed8aca.davem@redhat.com> In-Reply-To: <1088545330.1157.88.camel@jzny.localdomain> References: <200406290106.38304.dtor_core@ameritech.net> <20040629143202.3ae7093a.davem@redhat.com> <1088545330.1157.88.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: 6428 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 29 Jun 2004 17:42:10 -0400 jamal wrote: > netdev swallowed my response to Dmitry earlier. Bacchus > please flog the admin for me. > This fix will conflict with the other qdisc patch we are discussing. > Basically thats what my message to Dmitry was earlier. Should I back Dmitry's change out for now then? From hadi@cyberus.ca Tue Jun 29 15:16:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:16:42 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMGVgi014940 for ; Tue, 29 Jun 2004 15:16:32 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BfQtv-000446-ME for netdev@oss.sgi.com; Tue, 29 Jun 2004 18:16:27 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BfQts-0000qW-H8; Tue, 29 Jun 2004 18:16:24 -0400 Subject: Re: [PATCH] sch_prio - fix compile warning + some logic rearrangement in enqueue From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: dtor_core@ameritech.net, netdev@oss.sgi.com In-Reply-To: <20040629145015.41ed8aca.davem@redhat.com> References: <200406290106.38304.dtor_core@ameritech.net> <20040629143202.3ae7093a.davem@redhat.com> <1088545330.1157.88.camel@jzny.localdomain> <20040629145015.41ed8aca.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1088547379.1039.0.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jun 2004 18:16:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6429 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 Tue, 2004-06-29 at 17:50, David S. Miller wrote: > Should I back Dmitry's change out for now then? Yes please. cheers, jamal From davem@redhat.com Tue Jun 29 15:22:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:22:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMMJgi015425 for ; Tue, 29 Jun 2004 15:22:20 -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 i5TMM9e1007210; Tue, 29 Jun 2004 18:22:09 -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 i5TMM9000368; Tue, 29 Jun 2004 18:22: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 i5TMLinj012547; Tue, 29 Jun 2004 18:21:44 -0400 Date: Tue, 29 Jun 2004 15:21:48 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: dtor_core@ameritech.net, netdev@oss.sgi.com Subject: Re: [PATCH] sch_prio - fix compile warning + some logic rearrangement in enqueue Message-Id: <20040629152148.3800d4d8.davem@redhat.com> In-Reply-To: <1088547379.1039.0.camel@jzny.localdomain> References: <200406290106.38304.dtor_core@ameritech.net> <20040629143202.3ae7093a.davem@redhat.com> <1088545330.1157.88.camel@jzny.localdomain> <20040629145015.41ed8aca.davem@redhat.com> <1088547379.1039.0.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: 6430 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 29 Jun 2004 18:16:20 -0400 jamal wrote: > > On Tue, 2004-06-29 at 17:50, David S. Miller wrote: > > > Should I back Dmitry's change out for now then? > > Yes please. Will do. From hadi@cyberus.ca Tue Jun 29 15:22:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:22:48 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMMigi015521 for ; Tue, 29 Jun 2004 15:22:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BfQzy-0007M8-5R for netdev@oss.sgi.com; Tue, 29 Jun 2004 18:22:42 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BfQzw-0001We-IZ; Tue, 29 Jun 2004 18:22:40 -0400 Subject: Re: [PATCH] (2/4) packet scheduler bad TDIFF_SAFE in csz From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com In-Reply-To: <20040629144506.0649d217.davem@redhat.com> References: <20040629140016.4afeb36b@dell_ss3.pdx.osdl.net> <20040629144506.0649d217.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1088547756.1040.5.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jun 2004 18:22:37 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6431 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 That scheduler is only a relic. Nobody uses it ;-> Check the cofig help. Pretty sure if you study it youll find a lot more bugs. cheers, jamal On Tue, 2004-06-29 at 17:45, David S. Miller wrote: > On Tue, 29 Jun 2004 14:00:16 -0700 > Stephen Hemminger wrote: > > > This code in the csz scheduler, is just plain broken. The TDIFF_SAFE > > effectively expands to: > > unsigned long delay = now - q->t_c; > > if (delay > 0) { > > delay = 0; > > goto do_reset; > > } > > if (delay >> q->delta_log) > > > > So delay is always 0! I assume that what was originally intended > > is the to keep delay bounded to 1<delta_log. > > This bug has been there since day one, wow. > > Good spotting, applied. > > From dtor_core@ameritech.net Tue Jun 29 15:26:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:26:34 -0700 (PDT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMQBgi016063 for ; Tue, 29 Jun 2004 15:26:32 -0700 Received: from unknown (HELO core-wl.prvt.inr.net) (dtor?core@ameritech.net@68.72.45.79 with plain) by smtp814.mail.sc5.yahoo.com with SMTP; 29 Jun 2004 22:26:11 -0000 From: Dmitry Torokhov To: hadi@cyberus.ca Subject: Re: [PATCH] sch_prio - fix compile warning + some logic rearrangement in enqueue Date: Tue, 29 Jun 2004 17:26:10 -0500 User-Agent: KMail/1.6.2 Cc: "David S. Miller" , netdev@oss.sgi.com References: <200406290106.38304.dtor_core@ameritech.net> <20040629145015.41ed8aca.davem@redhat.com> <1088547379.1039.0.camel@jzny.localdomain> In-Reply-To: <1088547379.1039.0.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200406291726.10294.dtor_core@ameritech.net> X-archive-position: 6432 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 On Tuesday 29 June 2004 05:16 pm, jamal wrote: > > On Tue, 2004-06-29 at 17:50, David S. Miller wrote: > > > Should I back Dmitry's change out for now then? > > Yes please. > I'll be back ;) when your changes are committed. -- Dmitry From davem@redhat.com Tue Jun 29 15:28:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:28:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMSogi016393 for ; Tue, 29 Jun 2004 15:28:51 -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 i5TMShe1008533; Tue, 29 Jun 2004 18:28:43 -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 i5TMSh002065; Tue, 29 Jun 2004 18:28:43 -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 i5TMSH3t013683; Tue, 29 Jun 2004 18:28:18 -0400 Date: Tue, 29 Jun 2004 15:28:22 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) packet scheduler bad TDIFF_SAFE in csz Message-Id: <20040629152822.4fa2e1c4.davem@redhat.com> In-Reply-To: <1088547756.1040.5.camel@jzny.localdomain> References: <20040629140016.4afeb36b@dell_ss3.pdx.osdl.net> <20040629144506.0649d217.davem@redhat.com> <1088547756.1040.5.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: 6433 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 29 Jun 2004 18:22:37 -0400 jamal wrote: > That scheduler is only a relic. > Nobody uses it ;-> Check the cofig help. > Pretty sure if you study it youll find a lot more bugs. Right, but it is good that we fix the obvious ones when we can. Stephen's fix resulted in being able to simplify some PSCHED_* macros significantly. From shemminger@osdl.org Tue Jun 29 15:35:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:35:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMZLgi016849 for ; Tue, 29 Jun 2004 15:35: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 i5TMZ3G10765; Tue, 29 Jun 2004 15:35:03 -0700 Date: Tue, 29 Jun 2004 15:35:03 -0700 From: Stephen Hemminger To: "Kishore A K" Cc: , , netdev@oss.sgi.com Subject: [PATCH 2.6] Fix message age in bridge STP config packets Message-Id: <20040629153503.5d214fd0@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: 6434 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 This is a revised version of Kishore's patch to set message age appropriately in STP configuration packets. Signed-off-by: Kishore A K Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_stp.c b/net/bridge/br_stp.c --- a/net/bridge/br_stp.c 2004-06-29 14:45:50 -07:00 +++ b/net/bridge/br_stp.c 2004-06-29 14:45:50 -07:00 @@ -18,6 +18,11 @@ #include "br_private.h" #include "br_private_stp.h" +/* since time values in bpdu are in jiffies and then scaled (1/256) + * before sending, make sure that is at least one. + */ +#define MESSAGE_AGE_INCR ((HZ < 256) ? 1 : (HZ/256)) + static const char *br_port_state_names[] = { [BR_STATE_DISABLED] = "disabled", [BR_STATE_LISTENING] = "listening", @@ -157,24 +162,25 @@ bpdu.root_path_cost = br->root_path_cost; bpdu.bridge_id = br->bridge_id; bpdu.port_id = p->port_id; - bpdu.message_age = 0; - if (!br_is_root_bridge(br)) { + if (br_is_root_bridge(br)) + bpdu.message_age = 0; + else { struct net_bridge_port *root = br_get_port(br, br->root_port); - bpdu.max_age = root->message_age_timer.expires - jiffies; - - if (bpdu.max_age <= 0) bpdu.max_age = 1; + bpdu.message_age = br->max_age + - (root->message_age_timer.expires - jiffies) + + MESSAGE_AGE_INCR; } bpdu.max_age = br->max_age; bpdu.hello_time = br->hello_time; bpdu.forward_delay = br->forward_delay; - br_send_config_bpdu(p, &bpdu); - - p->topology_change_ack = 0; - p->config_pending = 0; - - mod_timer(&p->hold_timer, jiffies + BR_HOLD_TIME); + if (bpdu.message_age < br->max_age) { + br_send_config_bpdu(p, &bpdu); + p->topology_change_ack = 0; + p->config_pending = 0; + mod_timer(&p->hold_timer, jiffies + BR_HOLD_TIME); + } } /* called under bridge lock */ From shemminger@osdl.org Tue Jun 29 15:48:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:48:07 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMm2gi017409 for ; Tue, 29 Jun 2004 15:48: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 i5TMlpG12727; Tue, 29 Jun 2004 15:47:51 -0700 Date: Tue, 29 Jun 2004 15:47:51 -0700 From: Stephen Hemminger To: Jes Sorensen Cc: netdev@oss.sgi.com Subject: acenic: Unhandled event 0x24 Message-Id: <20040629154751.20f4772a@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: 6435 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 When the acenic gigabit ether card is under lots of receive pressure, it generates many (not excessive) console output about Unhandled event 0x24 I presume this is because the receive ring is getting over run and packet was dropped. Board info: [root@dev4-000 root]# lspci -v 00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 21) Flags: fast devsel 00:00.1 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01) Flags: bus master, medium devsel, latency 96 00:00.2 Host bridge: ServerWorks CNB20HE Host Bridge Flags: medium devsel 00:00.3 Host bridge: ServerWorks CNB20HE Host Bridge Flags: medium devsel 00:01.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corp. EtherExpress PRO/100+ Server Adapter (PILA8470B) Flags: bus master, medium devsel, latency 100, IRQ 20 Memory at febff000 (32-bit, non-prefetchable) I/O ports at 2200 [size=64] Memory at fea00000 (32-bit, non-prefetchable) [size=1M] Capabilities: [dc] Power Management version 2 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44) Subsystem: IBM NetFinity 10/100 Fast Ethernet Flags: bus master, medium devsel, latency 100, IRQ 16 I/O ports at 2240 Memory at febfec00 (32-bit, non-prefetchable) [size=32] Capabilities: [40] Power Management version 2 00:06.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04) (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 01c5 Flags: bus master, medium devsel, latency 248, IRQ 18 Memory at feb00000 (32-bit, non-prefetchable) Memory at f0000000 (32-bit, prefetchable) [size=128M] Capabilities: [dc] Power Management version 1 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) Subsystem: ServerWorks OSB4 South Bridge Flags: bus master, medium devsel, latency 0 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 64 I/O ports at 0700 [size=16] 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) (prog-if 10 [OHCI]) Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller Flags: bus master, medium devsel, latency 96, IRQ 19 Memory at febfd000 (32-bit, non-prefetchable) 02:01.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) Subsystem: Adaptec AIC-7899P U160/m Flags: bus master, 66Mhz, medium devsel, latency 100, IRQ 17 BIST result: 00 I/O ports at 4000 [disabled] Memory at efbff000 (64-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 02:01.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) Subsystem: Adaptec AIC-7899P U160/m Flags: bus master, 66Mhz, medium devsel, latency 100, IRQ 18 BIST result: 00 I/O ports at 4100 [disabled] Memory at efbfe000 (64-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 02:05.0 RAID bus controller: IBM SCSI RAID Adapter [ServeRAID] (rev 10) Subsystem: IBM ServeRAID-4H Flags: bus master, medium devsel, latency 100, IRQ 24 I/O ports at 4200 Memory at efa00000 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] Vital Product Data Capabilities: [48] Power Management version 2 02:06.0 Ethernet controller: Intel Corp. 82542 Gigabit Ethernet Controller (rev 03) Subsystem: IBM Netfinity Gigabit Ethernet SX Adapter Flags: bus master, medium devsel, latency 100, IRQ 25 Memory at efbc0000 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 05:02.0 SCSI storage controller: QLogic Corp. QLA2200 64-bit Fibre Channel Adapter (rev 05) Subsystem: QLogic Corp. QLA2200 Flags: bus master, 66Mhz, medium devsel, latency 96, IRQ 21 I/O ports at 7000 Memory at ec3ff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 1 05:03.0 SCSI storage controller: QLogic Corp. QLA2200 64-bit Fibre Channel Adapter (rev 05) Subsystem: QLogic Corp. QLA2200 Flags: bus master, 66Mhz, medium devsel, latency 96, IRQ 22 I/O ports at 7100 Memory at ec3fe000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 1 05:04.0 Ethernet controller: Netgear GA620 Gigabit Ethernet (rev 01) Subsystem: Netgear: Unknown device 0001 Flags: bus master, 66Mhz, medium devsel, latency 96, IRQ 23 Memory at ec3f8000 (32-bit, non-prefetchable) From shemminger@osdl.org Tue Jun 29 15:49:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 15:50:02 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5TMnwgi017705 for ; Tue, 29 Jun 2004 15:49:59 -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 i5TMn7G13274; Tue, 29 Jun 2004 15:49:07 -0700 Date: Tue, 29 Jun 2004 15:49:07 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) packet scheduler bad TDIFF_SAFE in csz Message-Id: <20040629154907.5a335900@dell_ss3.pdx.osdl.net> In-Reply-To: <1088549025.1046.12.camel@jzny.localdomain> References: <20040629140016.4afeb36b@dell_ss3.pdx.osdl.net> <20040629144506.0649d217.davem@redhat.com> <1088547756.1040.5.camel@jzny.localdomain> <20040629152822.4fa2e1c4.davem@redhat.com> <1088549025.1046.12.camel@jzny.localdomain> 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: 6436 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 29 Jun 2004 18:43:45 -0400 jamal wrote: > > Sounds like good logic to me. > BTW, that jiffies fix, statemnt from Steve: > > The downside is the overhead of a function call, and a cache miss in > > >get_jiffies_64. > > Is this overhead on 32 bit machines or applies on 64 bit as well? > Note that code is used in the fast path. jiffies.h #if (BITS_PER_LONG < 64) u64 get_jiffies_64(void); #else static inline u64 get_jiffies_64(void) { return (u64)jiffies; } #endif From jm@jm.kir.nu Tue Jun 29 18:51:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 18:51:34 -0700 (PDT) Received: from jm.kir.nu (adsl-64-175-31-62.dsl.snfc21.pacbell.net [64.175.31.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5U1pVgi026110 for ; Tue, 29 Jun 2004 18:51:31 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BfUE6-0001vT-TZ; Tue, 29 Jun 2004 18:49:30 -0700 Date: Tue, 29 Jun 2004 18:49:30 -0700 From: Jouni Malinen To: "Luis R. Rodriguez" Cc: Netdev , prism54-devel@prism54.org Subject: Re: Prism54 wpa update Message-ID: <20040630014930.GB7153@jm.kir.nu> References: <20040629192101.GB14482@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629192101.GB14482@ruslug.rutgers.edu> User-Agent: Mutt/1.5.6i X-archive-position: 6437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev On Tue, Jun 29, 2004 at 03:21:01PM -0400, Luis R. Rodriguez wrote: > I'll keep my latest wpa work/patch at the following URL: > > http://prism54.org/~mcgrof/prism54-wpa.diff Hmm.. I do not understand the change you did for priv->wpa processing. There seems to be some kind of misunderstanding on what DOT11_AUTHENABLE and DOT11_OID_MLMEAUTOLEVEL is set to in various mode. I do not fully understand what you mean with TKIP vs 802.1x. TKIP is an encryption algorithm like WEP. IEEE 802.1X is authentication protocol which can be used with IEEE 802.1X EAPOL-Key frames to distribute WEP keys _or_ with WPA to generate keying material for WPA 4-Way Handshake that will generate the data encryption keys. DOT11_AUTHENABLE should be set to DOT11_AUTH_OS for WPA modes (i.e., not _SK or _BOTH like you had in some cases). DOT11_AUTH_SK can only be used with static WEP configuration (i.e., not with WPA or with IEEE 802.1X when using dynamic WEP key generation). DOT11_AUTH_BOTH is likewise only reasonable for static WEP configuration since it includes _SK as an option. DOT11OID_MLMEAUTOLEVEL seems to be required to be DOT11_MLME_EXTENDED for all cases where WPA IE is used. -- Jouni Malinen PGP id EFC895FA From jgarzik@pobox.com Tue Jun 29 20:07:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 20:07: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.12.10/8.12.9) with SMTP id i5U372gi028306 for ; Tue, 29 Jun 2004 20:07:03 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfVQz-0005YE-5l; Wed, 30 Jun 2004 04:06:54 +0100 Message-ID: <40E22E40.7050202@pobox.com> Date: Tue, 29 Jun 2004 23:06:40 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 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 6 2.6.7-bk11] pcnet32: correctly program bcr32. References: <200406282025.i5SKPv211077@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200406282025.i5SKPv211077@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6438 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 FYI I forwarded patches #4 and #5 to Andrew before I left for vacation last Friday. I'll apply those Thursday when my workstation is up and running, and I am fully caught up. From hadi@cyberus.ca Tue Jun 29 20:30:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 20:30:03 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5U3Txgi032471 for ; Tue, 29 Jun 2004 20:30:00 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BfRKR-0006JL-M1 for netdev@oss.sgi.com; Tue, 29 Jun 2004 18:43:51 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BfRKO-0003hn-S3; Tue, 29 Jun 2004 18:43:49 -0400 Subject: Re: [PATCH] (2/4) packet scheduler bad TDIFF_SAFE in csz From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <20040629152822.4fa2e1c4.davem@redhat.com> References: <20040629140016.4afeb36b@dell_ss3.pdx.osdl.net> <20040629144506.0649d217.davem@redhat.com> <1088547756.1040.5.camel@jzny.localdomain> <20040629152822.4fa2e1c4.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1088549025.1046.12.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jun 2004 18:43:45 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6439 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 Sounds like good logic to me. BTW, that jiffies fix, statemnt from Steve: > The downside is the overhead of a function call, and a cache miss in > >get_jiffies_64. Is this overhead on 32 bit machines or applies on 64 bit as well? Note that code is used in the fast path. cheers, jamal On Tue, 2004-06-29 at 18:28, David S. Miller wrote: > On 29 Jun 2004 18:22:37 -0400 > jamal wrote: > > > That scheduler is only a relic. > > Nobody uses it ;-> Check the cofig help. > > Pretty sure if you study it youll find a lot more bugs. > > Right, but it is good that we fix the obvious ones when > we can. Stephen's fix resulted in being able to simplify > some PSCHED_* macros significantly. > > From jes@trained-monkey.org Tue Jun 29 22:41:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 22:41:11 -0700 (PDT) Received: from jaguar.mkp.net (jaguar.mkp.net [192.139.46.146]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5U5f5gi005959 for ; Tue, 29 Jun 2004 22:41:06 -0700 Received: from jes by jaguar.mkp.net with local (Exim 3.35 #1) id 1BfXqA-0006Zd-00; Wed, 30 Jun 2004 01:41:02 -0400 To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: acenic: Unhandled event 0x24 References: <20040629154751.20f4772a@dell_ss3.pdx.osdl.net> From: Jes Sorensen Date: 30 Jun 2004 01:41:01 -0400 In-Reply-To: <20040629154751.20f4772a@dell_ss3.pdx.osdl.net> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jes@wildopensource.com Precedence: bulk X-list: netdev >>>>> "Stephen" == Stephen Hemminger writes: Stephen> When the acenic gigabit ether card is under lots of receive Stephen> pressure, it generates many (not excessive) console output Stephen> about Unhandled event 0x24 Stephen> I presume this is because the receive ring is getting over Stephen> run and packet was dropped. Weird! This is another one thats not listed in the programming manual. I have never seen it spew out event 0x24 messages, no idea what they are for. If you want to add a patch to rate-limit it I would have no objections. Cheers, Jes From manfred@colorfullife.com Tue Jun 29 22:45:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 22:45:37 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5U5jDgi006351 for ; Tue, 29 Jun 2004 22:45:16 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5U5ilLw031170; Wed, 30 Jun 2004 07:44:48 +0200 Message-ID: <40E25328.8020102@colorfullife.com> Date: Wed, 30 Jun 2004 07:44:08 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Gigabit Ethernet support for forcedeth Content-Type: multipart/mixed; boundary="------------000500040204050103080607" X-archive-position: 6441 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 This is a multi-part message in MIME format. --------------000500040204050103080607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Attached is an update for the patch that adds support for the gigabit ethernet nic in the nForce 250 Gb chipset. There were two changes from the previous patch: - clear the PHY_HALF flag if the nic is in half duplex. - remove the setflags / setlen helper functions: the ring entries are visible to the hardware, I don't like the read/modify/write cycles. It passes my own tests with 100 MBit half duplex, 100 MB full duplex and 1 GBit full duplex. -- Manfred --------------000500040204050103080607 Content-Type: text/plain; name="candidate-5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="candidate-5.txt" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 7 // EXTRAVERSION = -mm2 --- 2.6/drivers/net/forcedeth.c 2004-06-30 07:27:50.330753976 +0200 +++ build-2.6/drivers/net/forcedeth.c 2004-06-30 07:27:25.579516736 +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,18 @@ * 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 * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -80,7 +86,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.25" +#define FORCEDETH_VERSION "0.28" #define DRV_NAME "forcedeth" #include @@ -124,6 +130,7 @@ enum { #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 @@ -133,7 +140,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 @@ -160,7 +167,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, @@ -169,6 +176,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 @@ -182,6 +191,9 @@ enum { NvRegMulticastMaskA = 0xB8, NvRegMulticastMaskB = 0xBC, + NvRegPhyInterface = 0xC0, +#define PHY_RGMII 0x10000000 + NvRegTxRingPhysAddr = 0x100, NvRegRxRingPhysAddr = 0x104, NvRegRingSizes = 0x108, @@ -190,12 +202,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 @@ -214,15 +226,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, @@ -254,34 +266,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 @@ -310,10 +351,10 @@ struct ring_desc { #define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ #define RX_RING 128 -#define TX_RING 16 +#define TX_RING 64 /* limited to 1 packet until we understand NV_TX_LASTPACKET */ -#define TX_LIMIT_STOP 10 -#define TX_LIMIT_START 5 +#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) @@ -323,12 +364,46 @@ struct ring_desc { #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) +#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. @@ -346,12 +421,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); @@ -371,7 +449,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; }; /* @@ -396,6 +474,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) { @@ -422,24 +506,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; @@ -461,19 +539,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 */ + msleep(500); + + /* must wait till reset is deasserted */ + while (miicontrol & BMCR_RESET) { + msleep(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); @@ -488,6 +664,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); } @@ -498,8 +676,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); @@ -521,8 +699,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); @@ -530,13 +708,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); } @@ -651,11 +830,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); @@ -670,10 +850,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++; } @@ -704,15 +883,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); } @@ -721,7 +898,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, @@ -738,7 +915,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], @@ -770,11 +947,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); { @@ -793,7 +969,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; } @@ -806,27 +982,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 = cpu_to_le32(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, @@ -876,9 +1067,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; @@ -886,11 +1077,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 = cpu_to_le32(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, */ /* @@ -904,7 +1097,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); @@ -913,41 +1106,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]; @@ -1036,6 +1257,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); } @@ -1043,16 +1266,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) { @@ -1069,47 +1338,75 @@ 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; + +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); + + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), + base + NvRegMisc1); + pci_push(base); + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); + + return retval; } 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; miistat = readl(base + NvRegMIIStatus); writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); + dprintk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); - miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); - if (miival & BMSR_ANEGCOMPLETE) { - nv_update_linkspeed(dev); - - if (netif_carrier_ok(dev)) { - nv_stop_rx(dev); + 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 { - 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)) { - netif_carrier_off(dev); - printk(KERN_INFO "%s: link down.\n", dev->name); - nv_stop_rx(dev); + if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + printk(KERN_INFO "%s: link down.\n", dev->name); + nv_stop_rx(dev); + } } - writel(np->linkspeed, base + NvRegLinkSpeed); - pci_push(base); } + 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) @@ -1136,7 +1433,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); @@ -1158,7 +1455,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 */ @@ -1211,21 +1508,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); @@ -1233,53 +1536,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); @@ -1291,17 +1572,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); @@ -1309,13 +1585,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); @@ -1324,6 +1596,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); @@ -1332,18 +1605,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; @@ -1448,6 +1730,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) @@ -1507,9 +1797,15 @@ 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) @@ -1517,6 +1813,42 @@ static int __devinit nv_probe(struct pci if (id->driver_data & DEV_NEED_TIMERIRQ) np->irqmask |= NVREG_IRQ_TIMER; + /* 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) { printk(KERN_INFO "forcedeth: unable to register netdev: %d\n", err); @@ -1570,21 +1902,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, }, { /* 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, + }, + { /* 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, + }, + { /* 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 = 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 = 0x00D6, + .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, @@ -1613,7 +2001,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.6/include/linux/pci_ids.h 2004-06-30 07:27:50.333753520 +0200 +++ build-2.6/include/linux/pci_ids.h 2004-06-30 07:03:57.948509176 +0200 @@ -1063,21 +1063,33 @@ #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_MCP3_AUDIO 0x00da #define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3_IDE 0x00d5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_3 0x00d6 +#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 @@ -1105,6 +1117,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 --------------000500040204050103080607-- From jgarzik@pobox.com Tue Jun 29 23:10:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Jun 2004 23:10:37 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5U6ARgi007340 for ; Tue, 29 Jun 2004 23:10:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfYIa-0008Kf-Qk; Wed, 30 Jun 2004 07:10:26 +0100 Message-ID: <40E25944.8010200@pobox.com> Date: Wed, 30 Jun 2004 02:10:12 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth References: <40E25328.8020102@colorfullife.com> In-Reply-To: <40E25328.8020102@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6442 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 Manfred Spraul wrote: > -#define FORCEDETH_VERSION "0.25" > +#define FORCEDETH_VERSION "0.28" does this mean that .26 and .27 will be submitted as separate patches? what is the goal for a 1.0.0 version? These days I try to encourage moving to a 1.0 version once things seem to be working and stable. > #define DRV_NAME "forcedeth" > > #include > @@ -124,6 +130,7 @@ enum { > #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 > @@ -133,7 +140,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 > @@ -160,7 +167,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, > @@ -169,6 +176,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 > @@ -182,6 +191,9 @@ enum { > NvRegMulticastMaskA = 0xB8, > NvRegMulticastMaskB = 0xBC, > > + NvRegPhyInterface = 0xC0, > +#define PHY_RGMII 0x10000000 > + > NvRegTxRingPhysAddr = 0x100, > NvRegRxRingPhysAddr = 0x104, > NvRegRingSizes = 0x108, > @@ -190,12 +202,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 > @@ -214,15 +226,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, > @@ -254,34 +266,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 > @@ -310,10 +351,10 @@ struct ring_desc { > #define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ > > #define RX_RING 128 > -#define TX_RING 16 > +#define TX_RING 64 > /* limited to 1 packet until we understand NV_TX_LASTPACKET */ > -#define TX_LIMIT_STOP 10 > -#define TX_LIMIT_START 5 > +#define TX_LIMIT_STOP 63 > +#define TX_LIMIT_START 62 what's with the "limited to 1 packet" comment? > /* rx/tx mac addr + type + vlan + align + slack*/ > #define RX_NIC_BUFSIZE (DEFAULT_MTU + 64) definition of DEFAULT_MTU is a bit silly ... why not just use ETH_DATA_LEN? > @@ -323,12 +364,46 @@ struct ring_desc { > #define OOM_REFILL (1+HZ/20) > #define POLL_WAIT (1+HZ/100) > > +#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. > @@ -346,12 +421,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); > @@ -371,7 +449,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; > }; has this driver been tested with the case where ethtool is used to force the media to a specific speed (such as 100mbit full duplex)? > /* > @@ -396,6 +474,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) > { > @@ -422,24 +506,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; > @@ -461,19 +539,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 */ > + msleep(500); > + > + /* must wait till reset is deasserted */ > + while (miicontrol & BMCR_RESET) { > + msleep(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); > @@ -488,6 +664,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); > } > > @@ -498,8 +676,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); > @@ -521,8 +699,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); > @@ -530,13 +708,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); > } > > @@ -651,11 +830,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); > @@ -670,10 +850,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++; > } > @@ -704,15 +883,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); > } > > @@ -721,7 +898,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, > @@ -738,7 +915,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], > @@ -770,11 +947,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); > { > @@ -793,7 +969,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; > } > @@ -806,27 +982,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 = cpu_to_le32(np->tx_ring[i].FlagLen); shouldn't this be le32_to_cpu() ? > 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, > @@ -876,9 +1067,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; > @@ -886,11 +1077,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 = cpu_to_le32(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, */ > > /* > @@ -904,7 +1097,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); > @@ -913,41 +1106,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]; > @@ -1036,6 +1257,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); some of these dprintk() would be more appropriate as verbose printks enabled and disabled using netif_msg_xxx bitmaps. > @@ -1043,16 +1266,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; > + } ditto, RE netif_msg > + 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; > + } > + } ditto > 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) { > @@ -1069,47 +1338,75 @@ 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; > + > +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); > + > + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), > + base + NvRegMisc1); > + pci_push(base); > + writel(np->linkspeed, base + NvRegLinkSpeed); > + pci_push(base); > + > + return retval; > } > > 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; > > miistat = readl(base + NvRegMIIStatus); > writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); > - printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); > + dprintk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); ditto, RE netif_msg_ > - miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); > - if (miival & BMSR_ANEGCOMPLETE) { > - nv_update_linkspeed(dev); > - > - if (netif_carrier_ok(dev)) { > - nv_stop_rx(dev); > + 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 { > - 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)) { > - netif_carrier_off(dev); > - printk(KERN_INFO "%s: link down.\n", dev->name); > - nv_stop_rx(dev); > + if (netif_carrier_ok(dev)) { > + netif_carrier_off(dev); > + printk(KERN_INFO "%s: link down.\n", dev->name); > + nv_stop_rx(dev); ditto, RE netif_msg_ > } > - writel(np->linkspeed, base + NvRegLinkSpeed); > - pci_push(base); > } > + dprintk(KERN_DEBUG "%s: link change notification done.\n", dev->name); ditto > } > > static irqreturn_t nv_nic_irq(int foo, void *data, struct pt_regs *regs) > @@ -1136,7 +1433,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); > @@ -1158,7 +1455,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 */ > @@ -1211,21 +1508,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); > > @@ -1233,53 +1536,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); your driver needs to call pci_set_dma_mask() and pci_set_consistent_dma_mask(). > + /* 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); > @@ -1291,17 +1572,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); > @@ -1309,13 +1585,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); > @@ -1324,6 +1596,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); > @@ -1332,18 +1605,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; > @@ -1448,6 +1730,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) > @@ -1507,9 +1797,15 @@ 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; > + } would it be faster to simply ensure that np->tx_flags is fixed-endian? > if (id->driver_data & DEV_IRQMASK_1) > np->irqmask = NVREG_IRQMASK_WANTED_1; > if (id->driver_data & DEV_IRQMASK_2) > @@ -1517,6 +1813,42 @@ static int __devinit nv_probe(struct pci > if (id->driver_data & DEV_NEED_TIMERIRQ) > np->irqmask |= NVREG_IRQ_TIMER; > > + /* 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)); > + } I recommend trying phy 0 after phy 31, _iff_ the scan found nothing. > + if (i != 32) { > + /* reset it */ > + phy_init(dev); > + } > + > err = register_netdev(dev); > if (err) { > printk(KERN_INFO "forcedeth: unable to register netdev: %d\n", err); > @@ -1570,21 +1902,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, > }, > { /* 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, > + }, > + { /* 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, > + }, > + { /* 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 = 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 = 0x00D6, > + .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, > @@ -1613,7 +2001,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"); module_param() use would be nice :) > --- 2.6/include/linux/pci_ids.h 2004-06-30 07:27:50.333753520 +0200 > +++ build-2.6/include/linux/pci_ids.h 2004-06-30 07:03:57.948509176 +0200 > @@ -1063,21 +1063,33 @@ > #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_MCP3_AUDIO 0x00da > #define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 > #define PCI_DEVICE_ID_NVIDIA_NFORCE3_IDE 0x00d5 > +#define PCI_DEVICE_ID_NVIDIA_NVENET_3 0x00d6 > +#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 > @@ -1105,6 +1117,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 a.korud@vector.com.pl Wed Jun 30 01:52:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 01:53:07 -0700 (PDT) Received: from lion.vector.com.pl (lion.vector.com.pl [81.210.9.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5U8qdgi016575 for ; Wed, 30 Jun 2004 01:52:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C45E7F.9408E889" Subject: PCI fix for some platforms Date: Wed, 30 Jun 2004 10:52:31 +0200 Message-ID: <80908CC5B2C9DB47AAF8C77892FCB44315F7C9@lion.vector.com.pl> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: PCI fix for some platforms Thread-Index: AcRef3tmILzf3BrFQWu3L2wWhTqA1g== From: "Andriy Korud" To: Cc: X-archive-position: 6443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.korud@vector.com.pl Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------_=_NextPart_001_01C45E7F.9408E889 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, i've noticed that on some platforms (noticed on PPC/XScale embedded) PCI = cacheline size is not initialized properly and therefore card uses slow = "PCI read memory" command instead of optimal "PCI read memory line", = which cause serious bendwidth limitations in case of 3+ cards on single = PCI bus. Attached patch that fix this issue - please merge review. regards, -- Andriy Korud =20 ------_=_NextPart_001_01C45E7F.9408E889 Content-Type: text/x-diff; name="pci-fix.patch" Content-Transfer-Encoding: base64 Content-Description: pci-fix.patch Content-Disposition: attachment; filename="pci-fix.patch" ZGlmZiAtdXIgcHJpc201NC1jdnMtbGF0ZXN0L2tzcmMvaXNscGNpX2Rldi5jIHByaXNtNTQtY3Zz LWxhdGVzdC1maXgva3NyYy9pc2xwY2lfZGV2LmMKLS0tIHByaXNtNTQtY3ZzLWxhdGVzdC9rc3Jj L2lzbHBjaV9kZXYuYwkyMDA0LTA1LTI5IDE4OjA2OjQ5LjAwMDAwMDAwMCArMDMwMAorKysgcHJp c201NC1jdnMtbGF0ZXN0LWZpeC9rc3JjL2lzbHBjaV9kZXYuYwkyMDA0LTA2LTI5IDE4OjUyOjAy LjAwNjUyMDMwNCArMDMwMApAQCAtNzczLDYgKzc3Myw3IEBACiBzdHJ1Y3QgbmV0X2RldmljZSAq CiBpc2xwY2lfc2V0dXAoc3RydWN0IHBjaV9kZXYgKnBkZXYpCiB7CisJdV9pbnQ4X3QgY3o7CiAJ aXNscGNpX3ByaXZhdGUgKnByaXY7CiAJc3RydWN0IG5ldF9kZXZpY2UgKm5kZXYgPSBhbGxvY19l dGhlcmRldihzaXplb2YgKGlzbHBjaV9wcml2YXRlKSk7CiAKQEAgLTc4NSw2ICs3ODYsMTIgQEAK IAlTRVRfTkVUREVWX0RFVihuZGV2LCAmcGRldi0+ZGV2KTsKICNlbmRpZgogCisJcGNpX3JlYWRf Y29uZmlnX2J5dGUocGRldiwgUENJX0NBQ0hFX0xJTkVfU0laRSwgJmNzeik7CisgICAgICAgIGlm IChjc3ogPT0gMCkgeworCQljc3ogPSBMMV9DQUNIRV9CWVRFUyAvIHNpemVvZih1X2ludDMyX3Qp OworCQlwY2lfd3JpdGVfY29uZmlnX2J5dGUocGRldiwgUENJX0NBQ0hFX0xJTkVfU0laRSwgY3N6 KTsKKwl9CisKIAkvKiBzZXR1cCB0aGUgc3RydWN0dXJlIG1lbWJlcnMgKi8KIAluZGV2LT5iYXNl X2FkZHIgPSBwY2lfcmVzb3VyY2Vfc3RhcnQocGRldiwgMCk7CiAJbmRldi0+aXJxID0gcGRldi0+ aXJxOwo= ------_=_NextPart_001_01C45E7F.9408E889-- From jgarzik@pobox.com Wed Jun 30 02:01:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 02:01: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.12.10/8.12.9) with SMTP id i5U91ugi017083 for ; Wed, 30 Jun 2004 02:01:57 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfayY-0003oj-MV; Wed, 30 Jun 2004 10:01:54 +0100 Message-ID: <40E28175.7090403@pobox.com> Date: Wed, 30 Jun 2004 05:01:41 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andriy Korud CC: netdev@oss.sgi.com, prism54-private@prism54.org Subject: Re: PCI fix for some platforms References: <80908CC5B2C9DB47AAF8C77892FCB44315F7C9@lion.vector.com.pl> In-Reply-To: <80908CC5B2C9DB47AAF8C77892FCB44315F7C9@lion.vector.com.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6444 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 Andriy Korud wrote: > Hi, > i've noticed that on some platforms (noticed on PPC/XScale embedded) PCI cacheline size is not initialized properly and therefore card uses slow "PCI read memory" command instead of optimal "PCI read memory line", which cause serious bendwidth limitations in case of 3+ cards on single PCI bus. > > Attached patch that fix this issue - please merge review. See pci_set_mwi() Jeff From christophe.varoqui@free.fr Wed Jun 30 04:03:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 04:03:20 -0700 (PDT) Received: from postfix3-1.free.fr (postfix@postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UB37gi023869 for ; Wed, 30 Jun 2004 04:03:07 -0700 Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix3-1.free.fr (Postfix) with ESMTP id 7B2A6173520 for ; Wed, 30 Jun 2004 12:27:27 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id 72C9C1E5A3; Wed, 30 Jun 2004 12:27:27 +0200 (MEST) Received: from proxy8.sncf.fr (proxy8.sncf.fr [171.16.4.10]) by imp3-q.free.fr (IMP) with HTTP for ; Wed, 30 Jun 2004 12:27:27 +0200 Message-ID: <1088591247.40e2958f5d8d3@imp3-q.free.fr> Date: Wed, 30 Jun 2004 12:27:27 +0200 From: christophe.varoqui@free.fr To: netdev@oss.sgi.com Subject: TCP RST problem MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i5UB37gi023869 X-archive-position: 6446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christophe.varoqui@free.fr Precedence: bulk X-list: netdev Hello, I got a strange problem : A weblogic app reply to a POST request by a 302 redirect. As soon as the "302" fragments are sent, the server emits a TCP RST. The client is then unable to do its consecutive GET ordered by the redirect : it shows a "404". Facts : This behaviour is reproductible on vanilla lk 2.4.26, latest redhat EL kernel and various Linux distros. This behaviour is not reproductible with Windows NT/XP weblogic servers and Tru64 servers. This behaviour shows only when using Internet Explorer at the client side : relyably with IE5, IE5.1, IE5.5 and less relyably with IE6. Mozilla browsers don't ever trigger the RST. Latest IE Service Packs seem to solve the problem too, but I don't have the leasure to force the upgrade on a *really* big client park (+4000 PC). Masking the Weblogic server behind a proxy or a LVS load-balancer mostly solve the issue : RST get triggered less than 1 hit out of 50. Droping the outgoing RST packets on the weblogic server fixes the problem 100%, but may induce other problems. Questions : Does anyone have insights to share about how to solve the problem "cleanly" on the server side, or simply an explanation of the phenomenon ? What perturbations can I expect from filtering the outgoing RST on these servers, given they will take hits from slow WAN clients ? regards, cvaroqui -- From jaap.keuter@xs4all.nl Wed Jun 30 04:02:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 04:02:26 -0700 (PDT) Received: from smtp-out1.xs4all.nl (smtp-out1.xs4all.nl [194.109.24.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UB2Igi023534 for ; Wed, 30 Jun 2004 04:02:18 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.21.2]) by smtp-out1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i5UB2Hxj068753; Wed, 30 Jun 2004 13:02:17 +0200 (CEST) Received: from xs1.xs4all.nl (skydiver@localhost.xs4all.nl [127.0.0.1]) by xs1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i5UB2Gfr087364; Wed, 30 Jun 2004 13:02:16 +0200 (CEST) (envelope-from jaap.keuter@xs4all.nl) Received: from localhost (skydiver@localhost) by xs1.xs4all.nl (8.12.10/8.12.9/Submit) with ESMTP id i5UB2GTO087361; Wed, 30 Jun 2004 13:02:16 +0200 (CEST) (envelope-from jaap.keuter@xs4all.nl) X-Authentication-Warning: xs1.xs4all.nl: skydiver owned process doing -bs Date: Wed, 30 Jun 2004 13:02:16 +0200 (CEST) From: Jaap Keuter X-X-Sender: skydiver@xs1.xs4all.nl To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [PATCH] broadcast address on subnet Message-ID: <20040630125858.K68876-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaap.keuter@xs4all.nl Precedence: bulk X-list: netdev Hello David and list, While getting hands-on with netkit (www.netkit.org), a networking simulation environment based on UML, it struck me that ifconfig wasn't capable of calculating the proper broadcast address for a subnetted interface. Some browsing through newsgroups and on the Debian package site (nettools), showed that this leads to misconfigured interfaces and a couple of bugreports on ifconfig. Digging a bit deeper revealed that it actually is an issue with SIOIFNETMASK. Once you bring up an interface with SIOIFADDR, a classfull netmask and broadcast address is set (if applicable for the type of interface), in order to get a properly configured interface. But if you subnet the network using SIOIFNETMASK no proper broadcast address is set. So you always have to calculate it yourself, obviously leading to configuration errors. This patch takes care of this. First of all it doesn't change existing functionality, eg. a command like 'ifconfig eth0 192.168.1.1 netmask 255.255.255.240 broadcast 192.168.1.0' still works. But if you omit the broadcast address, a proper 'all ones' broadcast address for the subnet is set. 'ifconfig eth0 192.168.1.1 netmask 255.255.255.240' gives you 'eth0 inet addr:192.168.1.1 Bcast:192.168.1.15 Mask:255.255.255.240' and this should solve some real life problems. The patch is created against kernel 2.4.26, but can easily be ported. Signed-off-by: Jaap Keuter --- linux-2.4.26/net/ipv4/devinet.c.orig 2004-04-14 13:05:41.000000000 +0000 +++ linux-2.4.26/net/ipv4/devinet.c 2004-06-23 11:28:36.000000000 +0000 @@ -661,8 +661,18 @@ if (ifa->ifa_mask != sin->sin_addr.s_addr) { inet_del_ifa(in_dev, ifap, 0); + ifa->ifa_prefixlen = inet_mask_len(sin->sin_addr.s_addr); + /* + * See if current broadcast address matches with current netmask, + * then recalculate the broadcast address. Otherwise it's a funny + * address, so don't touch it since the user seems to know what + * (s)he's doing... + */ + if ((dev->flags&IFF_BROADCAST) && (ifa->ifa_prefixlen < 31) && + (ifa->ifa_broadcast == (ifa->ifa_local|~ifa->ifa_mask))) { + ifa->ifa_broadcast = ifa->ifa_local|~sin->sin_addr.s_addr; + } ifa->ifa_mask = sin->sin_addr.s_addr; - ifa->ifa_prefixlen = inet_mask_len(ifa->ifa_mask); inet_insert_ifa(ifa); } break; From herbert@gondor.apana.org.au Wed Jun 30 04:28:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 04:29:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UBSugi028061 for ; Wed, 30 Jun 2004 04:28: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 1BfdFt-0002P5-00; Wed, 30 Jun 2004 21:27:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BfdFn-000872-00; Wed, 30 Jun 2004 21:27:51 +1000 Date: Wed, 30 Jun 2004 21:27:51 +1000 To: Alexey Kuznetsov Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040630112751.GA31160@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20040629111833.GA22880@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6447 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 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 29, 2004 at 09:18:33PM +1000, herbert wrote: > > > Or we can set the disconnected pid to a negative value since POSIX > > > requires pid_t to be signed. I see that you've reserved everything > > > between -4096 and 0. So perhaps we can pick -1? Actually that doesn't quite work. Users are allowed to bind to any non-zero address including -1. Besides, we already have sock->sk_state and socket->state which are perfect for this. So here is a patch to disallow sending unicast messages to connected sockets from addresses other than the one that it is connected to. I've tested it with a locally patched Openswan and it works as intended by stopping me from sending bogus messages to it and still allowing kernel messages to go through. 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/netlink/af_netlink.c 1.48 vs edited ===== --- 1.48/net/netlink/af_netlink.c 2004-06-19 04:43:31 +10:00 +++ edited/net/netlink/af_netlink.c 2004-06-30 20:53:00 +10:00 @@ -365,6 +365,7 @@ struct sockaddr_nl *nladdr=(struct sockaddr_nl*)addr; if (addr->sa_family == AF_UNSPEC) { + sock->state = SS_UNCONNECTED; nlk->dst_pid = 0; nlk->dst_groups = 0; return 0; @@ -380,6 +381,7 @@ err = netlink_autobind(sock); if (err == 0) { + sock->state = SS_CONNECTED; nlk->dst_pid = nladdr->nl_pid; nlk->dst_groups = nladdr->nl_groups; } @@ -428,6 +430,12 @@ /* Don't bother queuing skb if kernel socket has no input function */ nlk = nlk_sk(sock); if (nlk->pid == 0 && !nlk->data_ready) { + sock_put(sock); + return ERR_PTR(-ECONNREFUSED); + } + + if (sock->sk_socket->state == SS_CONNECTED && + nlk->dst_pid != nlk_sk(ssk)->pid) { sock_put(sock); return ERR_PTR(-ECONNREFUSED); } --9amGYk9869ThD9tj-- From herbert@gondor.apana.org.au Wed Jun 30 04:42:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 04:42:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UBgVgi028674 for ; Wed, 30 Jun 2004 04:42: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 1BfdTK-0002Wv-00; Wed, 30 Jun 2004 21:41:50 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BfdTE-00089i-00; Wed, 30 Jun 2004 21:41:44 +1000 Date: Wed, 30 Jun 2004 21:41:44 +1000 To: "David S. Miller" , Alexey Kuznetsov , netdev@oss.sgi.com Subject: [NETLINK] Return err in netlink_connect Message-ID: <20040630114144.GA31327@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6448 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 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch makes netlink_connect() return the value of err instead of 0. It doesn't actually make any difference since the current implementation of netlink_autobind() never fails. But since we went to all this trouble to check the return status of autobind, might as well return the correct 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 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/netlink/af_netlink.c 1.49 vs edited ===== --- 1.49/net/netlink/af_netlink.c 2004-06-30 21:28:39 +10:00 +++ edited/net/netlink/af_netlink.c 2004-06-30 21:36:36 +10:00 @@ -386,7 +386,7 @@ nlk->dst_groups = nladdr->nl_groups; } - return 0; + return err; } static int netlink_getname(struct socket *sock, struct sockaddr *addr, int *addr_len, int peer) --Kj7319i9nmIyA2yE-- From kuznet@ms2.inr.ac.ru Wed Jun 30 05:03:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 05:03:21 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UC3Igi029348 for ; Wed, 30 Jun 2004 05:03:19 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id QAA08039; Wed, 30 Jun 2004 16:00:45 +0400 Date: Wed, 30 Jun 2004 16:00:45 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040630120045.GA7973@ms2.inr.ac.ru> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040630112751.GA31160@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > + if (sock->sk_socket->state == SS_CONNECTED && > + nlk->dst_pid != nlk_sk(ssk)->pid) { No-no-no! sock->sk_socket can be NULL at this point. You can use sock->sk_state = TCP_ESTABLISHED, forxample. Alexey From herbert@gondor.apana.org.au Wed Jun 30 05:09:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 05:09:21 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UC9Dgi029884 for ; Wed, 30 Jun 2004 05:09: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 1BfdtA-0002j5-00; Wed, 30 Jun 2004 22:08:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bfdt6-0008Ch-00; Wed, 30 Jun 2004 22:08:28 +1000 Date: Wed, 30 Jun 2004 22:08:28 +1000 To: Alexey Kuznetsov Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040630120828.GA31498@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> <20040630120045.GA7973@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040630120045.GA7973@ms2.inr.ac.ru> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6450 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, Jun 30, 2004 at 04:00:45PM +0400, Alexey Kuznetsov wrote: > > > + if (sock->sk_socket->state == SS_CONNECTED && > > + nlk->dst_pid != nlk_sk(ssk)->pid) { > > No-no-no! sock->sk_socket can be NULL at this point. > > You can use sock->sk_state = TCP_ESTABLISHED, forxample. OK. Can you give me a code path that allows sk_socket to be NULL at this point? 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 kuznet@ms2.inr.ac.ru Wed Jun 30 05:16:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 05:16:55 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UCGqgi030378 for ; Wed, 30 Jun 2004 05:16:52 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id QAA08230; Wed, 30 Jun 2004 16:14:20 +0400 Date: Wed, 30 Jun 2004 16:14:20 +0400 From: Alexey Kuznetsov To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040630121420.GA8183@ms2.inr.ac.ru> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> <20040630120045.GA7973@ms2.inr.ac.ru> <20040630120828.GA31498@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040630120828.GA31498@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-archive-position: 6451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > OK. Can you give me a code path that allows sk_socket to be NULL > at this point? cpu 0: cpu1 (or just preempted cpu) sk = netlink_lookup(...); ... closing sk netlink_release() clears sk_socket use sk->sk_socket. Oops. Alexey From herbert@gondor.apana.org.au Wed Jun 30 05:41:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 05:41:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UCfcgi031802 for ; Wed, 30 Jun 2004 05:41: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 1BfeOU-00032l-00; Wed, 30 Jun 2004 22:40:54 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BfeOQ-0000RC-00; Wed, 30 Jun 2004 22:40:50 +1000 Date: Wed, 30 Jun 2004 22:40:50 +1000 To: Alexey Kuznetsov Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040630124050.GA1619@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> <20040630120045.GA7973@ms2.inr.ac.ru> <20040630120828.GA31498@gondor.apana.org.au> <20040630121420.GA8183@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <20040630121420.GA8183@ms2.inr.ac.ru> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6452 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 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 30, 2004 at 04:14:20PM +0400, Alexey Kuznetsov wrote: > > cpu 0: cpu1 (or just preempted cpu) > > sk = netlink_lookup(...); > ... closing sk > netlink_release() clears sk_socket > > use sk->sk_socket. Oops. Thanks for the example. Here is a version that uses sk_state 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 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/netlink.h 1.15 vs edited ===== --- 1.15/include/linux/netlink.h 2004-04-17 02:24:35 +10:00 +++ edited/include/linux/netlink.h 2004-06-30 22:34:18 +10:00 @@ -90,6 +90,11 @@ #define NET_MAJOR 36 /* Major 36 is reserved for networking */ +enum { + NETLINK_UNCONNECTED = 0, + NETLINK_CONNECTED, +}; + #ifdef __KERNEL__ #include ===== net/netlink/af_netlink.c 1.48 vs edited ===== --- 1.48/net/netlink/af_netlink.c 2004-06-19 04:43:31 +10:00 +++ edited/net/netlink/af_netlink.c 2004-06-30 22:34:24 +10:00 @@ -365,6 +365,7 @@ struct sockaddr_nl *nladdr=(struct sockaddr_nl*)addr; if (addr->sa_family == AF_UNSPEC) { + sk->sk_state = NETLINK_UNCONNECTED; nlk->dst_pid = 0; nlk->dst_groups = 0; return 0; @@ -380,6 +381,7 @@ err = netlink_autobind(sock); if (err == 0) { + sk->sk_state = NETLINK_CONNECTED; nlk->dst_pid = nladdr->nl_pid; nlk->dst_groups = nladdr->nl_groups; } @@ -428,6 +430,12 @@ /* Don't bother queuing skb if kernel socket has no input function */ nlk = nlk_sk(sock); if (nlk->pid == 0 && !nlk->data_ready) { + sock_put(sock); + return ERR_PTR(-ECONNREFUSED); + } + + if (sock->sk_state == NETLINK_CONNECTED && + nlk->dst_pid != nlk_sk(ssk)->pid) { sock_put(sock); return ERR_PTR(-ECONNREFUSED); } --VbJkn9YxBvnuCH5J-- From mcgrof@studorgs.rutgers.edu Wed Jun 30 07:01:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 07:01:08 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UE14gi001967 for ; Wed, 30 Jun 2004 07:01:05 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 27C1BF9D4D; Wed, 30 Jun 2004 10:01:04 -0400 (EDT) Date: Wed, 30 Jun 2004 10:01:04 -0400 To: Jeff Garzik Cc: Netdev , prism54-devel@prism54.org Subject: Re: Prism54 wpa update Message-ID: <20040630140104.GD14482@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , Netdev , prism54-devel@prism54.org References: <20040629192101.GB14482@ruslug.rutgers.edu> <20040629202210.GK23191@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629202210.GK23191@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: 6453 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 On Tue, Jun 29, 2004 at 04:22:10PM -0400, Jeff Garzik wrote: > On Tue, Jun 29, 2004 at 03:21:01PM -0400, Luis R. Rodriguez wrote: > > > > I'll keep my latest wpa work/patch at the following URL: > > > > http://prism54.org/~mcgrof/prism54-wpa.diff > > > > I've nuked module params and am relying on private ioctls now since, > > > > * we already have a [s|g]et_wpa priv iotcl, and > > * in preperation for the WPA patch for Wireless Extensions. > > > > I'll work on wpa ie scans tonight and try to fix mgt for > > handling traps in extended mode. This is not related to wpa, but > > I also made the firmware load at probe time. I turned the radio > > off at probe after firmware load time too since the device is > > not technically up yet. > > Patch seems sane, though I vaguely recall xchg() not being atomic on all > platforms (such as i386?). Maybe I'm wrong, an expert should speak up :) Just in case -- please don't apply the patch yet, I put it up as for review and update as to where I am. > I also worry that the following is a race, but I have not traced the > code to verify or discount my guess: > > + u32 mlme, authen, dot1x, filter, wep; > + > + > + if (islpci_get_state(priv) < PRV_STATE_INIT) > + return 0; > > down_write(&priv->mib_sem); FWIW, the context that this is within is prism54_set_wpa, a private ioctl. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From mcgrof@studorgs.rutgers.edu Wed Jun 30 08:13:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 08:13:54 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UFDkgi004507 for ; Wed, 30 Jun 2004 08:13:47 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 4762BF9D4E; Wed, 30 Jun 2004 11:13:46 -0400 (EDT) Date: Wed, 30 Jun 2004 11:13:46 -0400 To: Jouni Malinen Cc: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: Prism54 wpa update Message-ID: <20040630151346.GE14482@ruslug.rutgers.edu> Mail-Followup-To: Jouni Malinen , "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org References: <20040629192101.GB14482@ruslug.rutgers.edu> <20040630014930.GB7153@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040630014930.GB7153@jm.kir.nu> 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: 6454 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 On Tue, Jun 29, 2004 at 06:49:30PM -0700, Jouni Malinen wrote: > On Tue, Jun 29, 2004 at 03:21:01PM -0400, Luis R. Rodriguez wrote: > > > I'll keep my latest wpa work/patch at the following URL: > > > > http://prism54.org/~mcgrof/prism54-wpa.diff > > Hmm.. I do not understand the change you did for priv->wpa processing. > There seems to be some kind of misunderstanding on what DOT11_AUTHENABLE > and DOT11_OID_MLMEAUTOLEVEL is set to in various mode. First, thanks for the reply. In regards to MLME, that was just a big fat typo. > I do not fully > understand what you mean with TKIP vs 802.1x. TKIP is an encryption > algorithm like WEP. IEEE 802.1X is authentication protocol which can be > used with IEEE 802.1X EAPOL-Key frames to distribute WEP keys _or_ with > WPA to generate keying material for WPA 4-Way Handshake that will > generate the data encryption keys. Yes, sorry, what I was trying to distinguish was using WPA using either PSK or 802.1x for 4-way handshake. I did not know there were two 802.1x key mechanisms though, as you point out. Wherever I said just TKIP I meant over TKIP using a PSK. I believe the second mode of 802.1x can be used with this chipset, not sure of the first though (to distribute WEP keys). > DOT11_AUTHENABLE should be set to DOT11_AUTH_OS for WPA modes (i.e., not > _SK or _BOTH like you had in some cases). DOT11_AUTH_SK can only be used > with static WEP configuration (i.e., not with WPA or with IEEE 802.1X > when using dynamic WEP key generation). DOT11_AUTH_BOTH is likewise only > reasonable for static WEP configuration since it includes _SK as an > option. OS stands for Open System here. Are you sure of this? I'll ask around, just to confirm too. > DOT11OID_MLMEAUTOLEVEL seems to be required to be > DOT11_MLME_EXTENDED for all cases where WPA IE is used. Yes, this I am aware of this. I've regenerated my patch. This *is* what I meant. I think then we just need to clear up on what values should be set for AUTHENABLE. I assumed the filter settings should work as I noted but I am not yet sure obviously since I cannot test yet. Last note is just keep in my that the patch is not supposed to work, its more of work in progress, particularly turning the radio off involves more work than what I currently have there. That is what I spend last night working on. I'll try to finish that off first before I move on to trying to detect WPA IEs. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From jm@jm.kir.nu Wed Jun 30 08:47:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 08:47:37 -0700 (PDT) Received: from jm.kir.nu (adsl-69-108-209-115.dsl.pltn13.pacbell.net [69.108.209.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UFlVgi009957 for ; Wed, 30 Jun 2004 08:47:31 -0700 Received: from jm by jm.kir.nu with local (Exim 4.34) id 1BfhH2-000200-Ac; Wed, 30 Jun 2004 08:45:24 -0700 Date: Wed, 30 Jun 2004 08:45:24 -0700 From: Jouni Malinen To: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: Prism54 wpa update Message-ID: <20040630154523.GA7294@jm.kir.nu> References: <20040629192101.GB14482@ruslug.rutgers.edu> <20040630014930.GB7153@jm.kir.nu> <20040630151346.GE14482@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040630151346.GE14482@ruslug.rutgers.edu> User-Agent: Mutt/1.5.6i X-archive-position: 6456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 1798 Lines: 34 On Wed, Jun 30, 2004 at 11:13:46AM -0400, Luis R. Rodriguez wrote: > > algorithm like WEP. IEEE 802.1X is authentication protocol which can be > > used with IEEE 802.1X EAPOL-Key frames to distribute WEP keys _or_ with > > WPA to generate keying material for WPA 4-Way Handshake that will > > generate the data encryption keys. > > Yes, sorry, what I was trying to distinguish was using WPA using either > PSK or 802.1x for 4-way handshake. I did not know there were two 802.1x key > mechanisms though, as you point out. Wherever I said just TKIP I meant over TKIP > using a PSK. I believe the second mode of 802.1x can be used with this > chipset, not sure of the first though (to distribute WEP keys). I kind of though so, too, but the configuration did not match this at all.. WPA-PSK and WPA-EAP(IEEE 802.1X/RADIUS) should use the same settings for IEEE 802.11 auth alg and MLME auto level. > > DOT11_AUTHENABLE should be set to DOT11_AUTH_OS for WPA modes (i.e., not > > _SK or _BOTH like you had in some cases). DOT11_AUTH_SK can only be used > > with static WEP configuration (i.e., not with WPA or with IEEE 802.1X > > when using dynamic WEP key generation). DOT11_AUTH_BOTH is likewise only > > reasonable for static WEP configuration since it includes _SK as an > > option. > > OS stands for Open System here. Are you sure of this? I'll ask around, just to > confirm too. Yes, I'm sure. See IEEE 802.11 standard for details. Open System auth alg is required for WPA. Shared keys auth alg uses WEP, so the only to use it is to have pre-shared WEP keys. I don't remember whether FullMAC version of PrismGT driver has a separate mode for WPA, but if not, this oid needs to be OS. It certainly cannot be SK. -- Jouni Malinen PGP id EFC895FA From manfred@colorfullife.com Wed Jun 30 09:11:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 09:11:51 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UGBjgi011172 for ; Wed, 30 Jun 2004 09:11:46 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5UGBfLw003917; Wed, 30 Jun 2004 18:11:42 +0200 Message-ID: <40E2E618.5020601@colorfullife.com> Date: Wed, 30 Jun 2004 18:11:04 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth References: <40E25328.8020102@colorfullife.com> <40E25944.8010200@pobox.com> In-Reply-To: <40E25944.8010200@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6457 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: 3747 Lines: 135 Jeff Garzik wrote: > Manfred Spraul wrote: > >> -#define FORCEDETH_VERSION "0.25" >> +#define FORCEDETH_VERSION "0.28" > > > does this mean that .26 and .27 will be submitted as separate patches? > I think they were internal patches from Carl-Daniel. I think one of them was for wol support, the other one a bugfix. > what is the goal for a 1.0.0 version? > At least - wol support - ethtool support > These days I try to encourage moving to a 1.0 version once things seem > to be working and stable. > Ok. >> /* limited to 1 packet until we understand NV_TX_LASTPACKET */ >> -#define TX_LIMIT_STOP 10 >> -#define TX_LIMIT_START 5 >> +#define TX_LIMIT_STOP 63 >> +#define TX_LIMIT_START 62 > > > what's with the "limited to 1 packet" comment? > It's probably stale, I must check my docs. I'll remove it after some more testing. >> #define RX_NIC_BUFSIZE (DEFAULT_MTU + 64) > > > definition of DEFAULT_MTU is a bit silly ... why not just use > ETH_DATA_LEN? > Ok, I'll fix that. >> - u16 tx_flags; >> + u32 tx_flags; >> }; > > > has this driver been tested with the case where ethtool is used to > force the media to a specific speed (such as 100mbit full duplex)? > The driver doesn't support ethtool, so this was not tested. I have tested it with a cross-over cable to a natsemi nic and then forced link speeds on the natsemi nic with ethtool. >> >> - prd = &np->tx_ring[i]; >> + Flags = cpu_to_le32(np->tx_ring[i].FlagLen); > > > shouldn't this be le32_to_cpu() ? > Ups. You are right. I'll fix it and send you an updated patch. >> + dprintk(KERN_INFO "%s: reconfiguration for multicast lists.\n", >> + dev->name); >> nv_start_rx(dev); >> spin_unlock_irq(&np->lock); > > > some of these dprintk() would be more appropriate as verbose printks > enabled and disabled using netif_msg_xxx bitmaps. > I agree - dprintk on is too verbose and dprintk off is too quiet. I'll fix it in another patch. >> - /* 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); > > > your driver needs to call pci_set_dma_mask() and > pci_set_consistent_dma_mask(). > I'll add that. >> + np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID; >> + if (id->driver_data & DEV_NEED_LASTPACKET1) >> + np->tx_flags |= NV_TX2_LASTPACKET1; >> + } > > > would it be faster to simply ensure that np->tx_flags is fixed-endian? > Not really: the only use is ring_flags = cpu_to_le32( (skb->len-1) | tx_flags); Pre-swapping it would change that to ring_flags = cpu_to_le32(skb->len-1) | np->tx_flags; >> + 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)); >> + } > > > I recommend trying phy 0 after phy 31, _iff_ the scan found nothing. > A phy with id 0 is in isolate mode. It must be reconfigured before it can be used, and this is not yet handled. >> >> 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"); > > > module_param() use would be nice :) > Ok. -- Manfred From margitsw@t-online.de Wed Jun 30 10:45:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 10:45:47 -0700 (PDT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UHjggi013918 for ; Wed, 30 Jun 2004 10:45:43 -0700 Received: from fwd11.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1Bfj98-0001MZ-03; Wed, 30 Jun 2004 19:45:22 +0200 Received: from roglap.local (GoVkjvZXrex6uh-UpV9L-p2A7Vk-3YPScZaS84M+JA-rewvaLHa08f@[217.226.122.65]) by fwd11.sul.t-online.com with esmtp id 1Bfj8v-1wyPzs0; Wed, 30 Jun 2004 19:45:09 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 0/6 Linux-2.6.7-bk13] prism54 patches Date: Wed, 30 Jun 2004 19:38:48 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200406301938.48468.margitsw@t-online.de> X-Seen: false X-ID: GoVkjvZXrex6uh-UpV9L-p2A7Vk-3YPScZaS84M+JA-rewvaLHa08f X-archive-position: 6458 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: 414 Lines: 10 Please apply following patches : [PATCH 1/6 Linux-2.6.7-bk13] prism54 : Cleanup functions [PATCH 2/6 Linux-2.6.7-bk13] prism54 : Missing error check [PATCH 3/6 Linux-2.6.7-bk13] prism54 : Fix likely thinko [PATCH 4/6 Linux-2.6.7-bk13] prism54 : Cleanup the device list [PATCH 5/6 Linux-2.6.7-bk13] prism54 : Remove poke into programmable registers [PATCH 6/6 Linux-2.6.7-bk13] prism54 : Use pci_set_mwi() Margit From margitsw@t-online.de Wed Jun 30 10:48:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 10:48:20 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UHmFgi014268 for ; Wed, 30 Jun 2004 10:48:16 -0700 Received: from fwd01.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1BfjBb-000237-02; Wed, 30 Jun 2004 19:47:55 +0200 Received: from roglap.local (JJSQlUZTQeQo10vlmlxhDA0rcWGByYNBxaw1DaQ1HknxDNJbDlBe8c@[217.226.122.65]) by fwd01.sul.t-online.com with esmtp id 1BfjBM-1DuK360; Wed, 30 Jun 2004 19:47:40 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 4/6 Linux-2.6.7-bk13] prism54 device list cleanup Date: Wed, 30 Jun 2004 19:41:19 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_/sv4AYaDFFrlNJz" Message-Id: <200406301941.19873.margitsw@t-online.de> X-Seen: false X-ID: JJSQlUZTQeQo10vlmlxhDA0rcWGByYNBxaw1DaQ1HknxDNJbDlBe8c X-archive-position: 6459 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: 6343 Lines: 247 --Boundary-00=_/sv4AYaDFFrlNJz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-06-28 Margit Schubert-While * Clean up the device table --Boundary-00=_/sv4AYaDFFrlNJz Content-Type: text/x-diff; charset="us-ascii"; name="04_pci_devices.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="04_pci_devices.patch" diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.7-02/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.6.7-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.7-02/drivers/net/wireless/prism54/islpci_hotplug.c 2004-06-25 20:14:46.000000000 +0200 @@ -38,81 +38,111 @@ /* In this order: vendor, device, subvendor, subdevice, class, class_mask, * driver_data - * Note: for driver_data we put the device's name * 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, - (unsigned long) "3COM 3CRWE154G72 Wireless LAN adapter"}, + 0, 0, 0 + }, + + /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_DLINK, 0x3202UL, - 0, 0, - (unsigned long) "D-Link Air Plus Xtreme G A1 - DWL-g650 A1"}, + 0, 0, 0 + }, + + /* I-O Data WN-G54/CB - WN-G54/CB */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_IODATA, 0xd019UL, - 0, 0, - (unsigned long) "I-O Data WN-G54/CB - WN-G54/CB"}, + 0, 0, 0 + }, + + /* Netgear WG511 */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_NETGEAR, 0x4800UL, - 0, 0, - (unsigned long) "Netgear WG511"}, + 0, 0, 0 + }, + + /* Tekram Technology clones, Allnet, Netcomm, Zyxel */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0020UL, - 0, 0, - (unsigned long) "PLANEX GW-DS54G"}, + PCIVENDOR_TTL, 0x1605UL, + 0, 0, 0 + }, + + /* SMC2802W */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_SMC, 0x2802UL, - 0, 0, - (unsigned long) "EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card - SMC2802W"}, + 0, 0, 0 + }, + + /* SMC2835W */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_SMC, 0x2835UL, - 0, 0, - (unsigned long) "EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Adapter - SMC2835W"}, + 0, 0, 0 + }, + + /* Corega CG-WLCB54GT */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_INTERSIL, 0x0000UL, /* This was probably a bogus reading... */ - 0, 0, - (unsigned long) "SparkLAN WL-850F"}, + PCIVENDOR_ATI, 0xc104UL, + 0, 0, 0 + }, + + /* I4 Z-Com XG-600 */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_I4, 0x0014UL, - 0, 0, - (unsigned long) "I4 Z-Com XG-600"}, + 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, - (unsigned long) "I4 Z-Com XG-900/PLANEX GW-DS54G"}, + 0, 0, 0 + }, + + /* SMC 2802W V2 */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_ACCTON, 0xee03UL, - 0, 0, - (unsigned long) "SMC 2802Wv2"}, + 0, 0, 0 + }, + + /* SMC 2835W V2 */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCIVENDOR_SMC, 0xa835UL, - 0, 0, - (unsigned long) "SMC 2835Wv2"}, + 0, 0, 0 + }, + + /* Intersil PRISM Indigo Wireless LAN adapter */ { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, PCI_ANY_ID, PCI_ANY_ID, - 0, 0, - (unsigned long) "Intersil PRISM Indigo Wireless LAN adapter"}, - { /* Default */ + 0, 0, 0 + }, + + /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ + /* Default */ + { PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, PCI_ANY_ID, PCI_ANY_ID, - 0, 0, - (unsigned long) "Intersil PRISM Duette/Prism GT Wireless LAN adapter"}, - {0,} + 0, 0, 0 + }, + + /* End of list */ + {0,0,0,0,0,0,0} }; /* register the device with the Hotplug facilities of the kernel */ @@ -138,12 +168,16 @@ { 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; @@ -161,12 +195,20 @@ 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 @@ -177,10 +219,10 @@ /* We have two reported for the one below :( */ case 0x0014UL: - modelp = "XG-600"; + modelp = "I4 Z-Com XG-600 and clones"; break; case 0x0020UL: - modelp = "XG-900/GW-DS54G"; + modelp = "I4 Z-Com XG-900 and clones"; break; /* Default it */ /* @@ -193,6 +235,10 @@ } 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; } diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/islpci_mgt.h linux-2.6.7-02/drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.6.7-01/drivers/net/wireless/prism54/islpci_mgt.h 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.7-02/drivers/net/wireless/prism54/islpci_mgt.h 2004-06-25 20:14:46.000000000 +0200 @@ -46,8 +46,11 @@ #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 --Boundary-00=_/sv4AYaDFFrlNJz-- From mcgrof@studorgs.rutgers.edu Wed Jun 30 11:28:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 11:28:49 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UISSgi015503 for ; Wed, 30 Jun 2004 11:28:28 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 209D7F9D9E; Wed, 30 Jun 2004 13:49:17 -0400 (EDT) Date: Wed, 30 Jun 2004 13:49:17 -0400 To: Margit Schubert-While Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 0/6 Linux-2.6.7-bk13] prism54 patches Message-ID: <20040630174917.GI14482@ruslug.rutgers.edu> Mail-Followup-To: Margit Schubert-While , jgarzik@pobox.com, netdev@oss.sgi.com References: <200406301938.48468.margitsw@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406301938.48468.margitsw@t-online.de> 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: 6460 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: 635 Lines: 19 Please CC prism54-devel for archiving :) Luis On Wed, Jun 30, 2004 at 07:38:48PM +0200, Margit Schubert-While wrote: > Please apply following patches : > [PATCH 1/6 Linux-2.6.7-bk13] prism54 : Cleanup functions > [PATCH 2/6 Linux-2.6.7-bk13] prism54 : Missing error check > [PATCH 3/6 Linux-2.6.7-bk13] prism54 : Fix likely thinko > [PATCH 4/6 Linux-2.6.7-bk13] prism54 : Cleanup the device list > [PATCH 5/6 Linux-2.6.7-bk13] prism54 : Remove poke into programmable registers > [PATCH 6/6 Linux-2.6.7-bk13] prism54 : Use pci_set_mwi() > > Margit > -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From shemminger@osdl.org Wed Jun 30 11:38:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 11:38:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UIc7gi015923 for ; Wed, 30 Jun 2004 11:38:07 -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 i5UIbsG04198; Wed, 30 Jun 2004 11:37:54 -0700 Date: Wed, 30 Jun 2004 11:37:54 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6] allow large MTU on dummy net device Message-Id: <20040630113754.5ae6b14a@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: 6461 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: 594 Lines: 17 It is useful for testing to allow larger MTU value to be set on the dummy network device. The current code limits it to valid Ether mtu's. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/dummy.c b/drivers/net/dummy.c --- a/drivers/net/dummy.c 2004-06-30 11:37:38 -07:00 +++ b/drivers/net/dummy.c 2004-06-30 11:37:38 -07:00 @@ -78,6 +78,7 @@ /* Fill in device structure with ethernet-generic values. */ ether_setup(dev); dev->tx_queue_len = 0; + dev->change_mtu = NULL; dev->flags |= IFF_NOARP; dev->flags &= ~IFF_MULTICAST; SET_MODULE_OWNER(dev); From greearb@candelatech.com Wed Jun 30 11:46:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 11:46:44 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UIkegi016402 for ; Wed, 30 Jun 2004 11:46:40 -0700 Received: from candelatech.com (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 i5UIvDSb003487; Wed, 30 Jun 2004 11:57:13 -0700 Message-ID: <40E30A8E.6000507@candelatech.com> Date: Wed, 30 Jun 2004 11:46:38 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] New version of net timestamp optimization References: <20040406182941.7e759f4c.ak@suse.de> <1081340659.15893.117.camel@jzny.localdomain> <20040407143703.6af5bb71.ak@suse.de> In-Reply-To: <20040407143703.6af5bb71.ak@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6462 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: 938 Lines: 34 Andi Kleen wrote: > On 07 Apr 2004 08:24:19 -0400 > jamal wrote: > > >>The patch does look clean and attractive. I havent had time toi play >>with it myself - but given the way gettimeofday has been torturing me >>i will at some point. Also if you have time a 2.4.x patch would be > > > Thanks. All feedback I received so far was positive. I hope DaveM will > merge it soon. I don't have plans to work on 2.4 anymore. I finally got around to working with 2.6, and I ran into the new timestamp code. I would like to be able to have timestamps even though I do not have a socket structure (I am using a kernel module to grab all frames)... How would you feel about either exporting the netstamp_needed variable or offering a method that explicitly incremented or decremented the use count? Thanks, Ben > > -Andi > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From manfred@colorfullife.com Wed Jun 30 11:56:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 11:56:28 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UIuFgi016883 for ; Wed, 30 Jun 2004 11:56:16 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5UIuBLw005076; Wed, 30 Jun 2004 20:56:12 +0200 Message-ID: <40E30CA7.3020209@colorfullife.com> Date: Wed, 30 Jun 2004 20:55:35 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth References: <40E25328.8020102@colorfullife.com> <40E25944.8010200@pobox.com> <40E2E618.5020601@colorfullife.com> In-Reply-To: <40E2E618.5020601@colorfullife.com> Content-Type: multipart/mixed; boundary="------------000006020406060009000704" X-archive-position: 6463 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: 3433 Lines: 104 This is a multi-part message in MIME format. --------------000006020406060009000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manfred Spraul wrote: >> >> your driver needs to call pci_set_dma_mask() and >> pci_set_consistent_dma_mask(). >> > I'll add that. > I've checked the pci layer: 32-bit is the default, thus no calls are required. What's missing is error handling for pci_map, I'll add that later. Attached is an incremental patch that fixes the simple issues you mentioned. Could you merge both patches together to your tree? They improve the driver significantly and I want some test input from users. I've added message flags and pci_map error handling to my todo list. -- Manfred --------------000006020406060009000704 Content-Type: text/plain; name="patch-forced-candidate-inc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forced-candidate-inc" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 7 // EXTRAVERSION = -mm2 --- 2.6/drivers/net/forcedeth.c 2004-06-30 18:45:23.000000000 +0200 +++ build-2.6/drivers/net/forcedeth.c 2004-06-30 18:45:05.000000000 +0200 @@ -348,18 +348,22 @@ 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 64 -/* limited to 1 packet until we understand NV_TX_LASTPACKET */ +/* + * 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) @@ -988,7 +992,7 @@ static void nv_tx_done(struct net_device while (np->nic_tx != np->next_tx) { i = np->nic_tx % TX_RING; - Flags = cpu_to_le32(np->tx_ring[i].FlagLen); + 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, Flags); @@ -1077,7 +1081,7 @@ static void nv_rx_process(struct net_dev break; /* we scanned the whole ring - do not continue */ i = np->cur_rx % RX_RING; - Flags = cpu_to_le32(np->rx_ring[i].FlagLen); + 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", @@ -1193,7 +1197,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; @@ -1999,7 +2003,7 @@ static void __exit exit_nic(void) pci_unregister_driver(&driver); } -MODULE_PARM(max_interrupt_work, "i"); +module_param(max_interrupt_work, int, 0); MODULE_PARM_DESC(max_interrupt_work, "forcedeth maximum events handled per interrupt"); MODULE_AUTHOR("Manfred Spraul "); --------------000006020406060009000704-- From andre@tomt.net Wed Jun 30 12:54:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 12:54:55 -0700 (PDT) Received: from mail.skjellin.no (ns1.skjellin.no [80.239.42.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UJsngi021551 for ; Wed, 30 Jun 2004 12:54:50 -0700 Received: (qmail 17409 invoked from network); 30 Jun 2004 19:36:41 -0000 Received: from unknown (HELO ?10.255.1.10?) (andre@skjellin.no@80.239.42.1) by mail.skjellin.no with SMTP; 30 Jun 2004 19:36:41 -0000 Message-ID: <40E316C4.30205@tomt.net> Date: Wed, 30 Jun 2004 21:38:44 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [Fwd: Remote DoS vulnerability in Linux kernel 2.6.x] Content-Type: multipart/mixed; boundary="------------050502080407020203090706" X-archive-position: 6464 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: 5312 Lines: 148 This is a multi-part message in MIME format. --------------050502080407020203090706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I would guess you guys know about this one - but just in case. Is the patch provided safe? Is the problem real? --------------050502080407020203090706 Content-Type: message/rfc822; name="Remote DoS vulnerability in Linux kernel 2.6.x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Remote DoS vulnerability in Linux kernel 2.6.x" Return-Path: Delivered-To: andre@tomt.net Received: (qmail 20334 invoked by uid 107); 30 Jun 2004 19:09:12 -0000 Received: from bugtraq-return-14993-andre=tomt.net@securityfocus.com by ns1 by uid 1003 with qmail-scanner-1.21 (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:0(205.206.231.26):SA:0(1.9/5.0):. Processed in 1.463814 secs); 30 Jun 2004 19:09:12 -0000 X-Spam-Level: * Received: from unknown (HELO outgoing2.securityfocus.com) (205.206.231.26) by mail.skjellin.no with SMTP; 30 Jun 2004 19:09:10 -0000 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id 8E2F0143784; Wed, 30 Jun 2004 17:49:20 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 30875 invoked from network); 30 Jun 2004 04:45:26 -0000 Date: Wed, 30 Jun 2004 12:57:17 +0200 From: Adam Osuchowski To: bugtraq@securityfocus.com Subject: Remote DoS vulnerability in Linux kernel 2.6.x Message-ID: <20040630105717.GA4294@polsl.gliwice.pl> Reply-To: Adam Osuchowski Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Computer Centre of The Silesian University of Technology X-nic-hdl: AO3196-RIPE X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ns1.skjellin.no X-Spam-Status: No, hits=1.9 required=5.0 tests=DATE_IN_FUTURE_06_12 autolearn=no version=2.63 1. Overview ----------- There is a remotely exploitable bug in all Linux kernel 2.6 series due to using incorrect variable type. Vulnerability is connected to netfilter subsystem and may cause DoS. It's disclosed only when using iptables with rules matching TCP options (i.e. --tcp-option). There is no difference what action is taking up by matching rule. Vulnerability was detected on i386 architecture. The other ones weren't tested but it seems to be vulnerable too. 2. Details ---------- Problem lies in tcp_find_option() function (net/ipv4/netfilter/ip_tables.c). There is local array `opt' defined as: char opt[60 - sizeof(struct tcphdr)]; which contains TCP options extracted from packet. Function mentioned above searches for specified option in this array. Options in TCP packet, with some exceptions, are organized in the following way: Octet no. Length Field ----------------------------- 0 1 Opcode 1 1 Length of all option (N + 2) 2 N Params The function iterates over options in array: for (i = 0; i < optlen; ) { if (opt[i] == option) return !invert; if (opt[i] < 2) i++; else i += opt[i+1]?:1; } moving counter by the option length. But, in case the `length' value is greater than 127, the value of this octet in `opt' is implicitly casted to char, which results in negative number and the loop counter moving back. In some cases it is possible, that counter cycles throught the contents of this array infinitely. 3. Impact --------- After sending one suitably prepared TCP packet to victim host, kernel goes into infinite loop consuming all CPU resources, rendering the box unresponsable. Of course, there is no need to have a shell access to attacked host. 4. Exploitation --------------- Example of packet-of-death: 0x0000: 4500 0030 1234 4000 ff06 e83f c0a8 0001 0x0010: c0a8 0002 0400 1000 0000 0064 0000 0064 0x0020: 7000 0fa0 dc6a 0000 0204 05b4 0101 04fd 5. Fix ------ There is only need to change type of `opt' array from signed char to unsigned (or, better to u_int8_t) as it was defined in 2.4 kernel or prior to version 1.16 of net/ipv4/netfilter/ip_tables.c file. --- net/ipv4/netfilter/ip_tables.c.orig 2004-04-04 05:36:47.000000000 +0200 +++ net/ipv4/netfilter/ip_tables.c 2004-06-24 21:24:26.000000000 +0200 @@ -1461,7 +1461,7 @@ int *hotdrop) { /* tcp.doff is only 4 bits, ie. max 15 * 4 bytes */ - char opt[60 - sizeof(struct tcphdr)]; + u_int8_t opt[60 - sizeof(struct tcphdr)]; unsigned int i; duprintf("tcp_match: finding option\n"); 6. Credits ---------- Vulnerability was discovered, identified and fixed by Adam Osuchowski and Tomasz Dubinski. -- ## Adam Osuchowski adwol@polsl.gliwice.pl, adwol@silesia.linux.org.pl ## Silesian University of Technology, Computer Centre Gliwice, Poland --------------050502080407020203090706-- From jgarzik@pobox.com Wed Jun 30 13:18:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 13:19:02 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UKIvgi022435 for ; Wed, 30 Jun 2004 13:18:58 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BflXj-0006cY-VX; Wed, 30 Jun 2004 21:18:56 +0100 Message-ID: <40E32021.6040800@pobox.com> Date: Wed, 30 Jun 2004 16:18:41 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com Subject: Re: [PATCH 4/6 Linux-2.6.7-bk13] prism54 device list cleanup References: <200406301941.19873.margitsw@t-online.de> In-Reply-To: <200406301941.19873.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6465 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: 1688 Lines: 46 Margit Schubert-While wrote: > 2004-06-28 Margit Schubert-While > > * Clean up the device table > > > ------------------------------------------------------------------------ > > diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.7-02/drivers/net/wireless/prism54/islpci_hotplug.c > --- linux-2.6.7-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-06-25 19:48:40.000000000 +0200 > +++ linux-2.6.7-02/drivers/net/wireless/prism54/islpci_hotplug.c 2004-06-25 20:14:46.000000000 +0200 > @@ -38,81 +38,111 @@ > > /* In this order: vendor, device, subvendor, subdevice, class, class_mask, > * driver_data > - * Note: for driver_data we put the device's name > * 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, > - (unsigned long) "3COM 3CRWE154G72 Wireless LAN adapter"}, > + 0, 0, 0 > + }, > + > + /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ > { > PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, > PCIVENDOR_DLINK, 0x3202UL, > - 0, 0, > - (unsigned long) "D-Link Air Plus Xtreme G A1 - DWL-g650 A1"}, > + 0, 0, 0 > + }, Patch is OK, but two comments: 1) use standard constants from include/linux/pci_ids.h, not your own 2) where possible, use PCI_ANY_ID for subvendor id and subdevice id. Experience shows that unless the subvendor/subdevice is absolutely required, it should not be specified. From romieu@fr.zoreil.com Wed Jun 30 13:34:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 13:34:59 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UKYqgi023063 for ; Wed, 30 Jun 2004 13:34:53 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i5UKXlon023775; Wed, 30 Jun 2004 22:33:47 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i5UKXkAZ023774; Wed, 30 Jun 2004 22:33:46 +0200 Date: Wed, 30 Jun 2004 22:33:46 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: alan@redhat.com, akpm@osdl.org, jgarzik@pobox.com Subject: [PATCH 2.6.7-mm3 1/1] via-velocity: use common crc16 code for WOL Message-ID: <20040630223346.A23520@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 6466 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: 5224 Lines: 163 - use common crc16 code for WOL; - remove unused ether_crc. Signed-off-by: Francois Romieu diff -puN drivers/net/via-velocity.c~via-velocity-110 drivers/net/via-velocity.c --- linux-2.6.7/drivers/net/via-velocity.c~via-velocity-110 2004-06-30 22:31:05.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/via-velocity.c 2004-06-30 22:31:05.000000000 +0200 @@ -78,6 +78,8 @@ #include #include #include +#include +#include #include "via-velocity.h" @@ -2053,32 +2055,6 @@ static int velocity_intr(int irq, void * /** - * ether_crc - ethernet CRC function - * - * Compute an ethernet CRC hash of the data block provided. This - * is not performance optimised but is not needed in performance - * critical code paths. - * - * FIXME: could we use shared code here ? - */ - -static inline u32 ether_crc(int length, unsigned char *data) -{ - static unsigned const ethernet_polynomial = 0x04c11db7U; - - int crc = -1; - - while (--length >= 0) { - unsigned char current_octet = *data++; - int bit; - for (bit = 0; bit < 8; bit++, current_octet >>= 1) { - crc = (crc << 1) ^ ((crc < 0) ^ (current_octet & 1) ? ethernet_polynomial : 0); - } - } - return crc; -} - -/** * velocity_set_multi - filter list change callback * @dev: network device * @@ -3082,83 +3058,6 @@ static void velocity_restore_context(str } -/* - * Purpose: Functions to set WOL. - */ - -const static unsigned short crc16_tab[256] = { - 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, - 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, - 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, - 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, - 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, - 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, - 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, - 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, - 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, - 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, - 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, - 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, - 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, - 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, - 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, - 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, - 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, - 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, - 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, - 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, - 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, - 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, - 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, - 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, - 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, - 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, - 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, - 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, - 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, - 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, - 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, - 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 -}; - -/** - * ether_crc16 - compute ethernet CRC - * @len: buffer length - * @cp: buffer - * @crc16: initial CRC - * - * Compute a CRC value for a block of data. - * FIXME: can we use generic functions ? - */ - -static u16 ether_crc16(int len, u8 * cp, u16 crc16) -{ - while (len--) - crc16 = (crc16 >> 8) ^ crc16_tab[(crc16 ^ *cp++) & 0xff]; - return (crc16); -} - -/** - * bit_reverse - 16bit reverse - * @data: 16bit data t reverse - * - * Reverse the order of a 16bit value and return the reversed bits - */ - -static u16 bit_reverse(u16 data) -{ - u32 new = 0x00000000; - int ii; - - - for (ii = 0; ii < 16; ii++) { - new |= ((u32) (data & 1) << (31 - ii)); - data >>= 1; - } - - return (u16) (new >> 16); -} - /** * wol_calc_crc - WOL CRC * @pattern: data pattern @@ -3187,12 +3086,12 @@ u16 wol_calc_crc(int size, u8 * pattern, continue; } mask >>= 1; - crc = ether_crc16(1, &(pattern[i * 8 + j]), crc); + crc = crc16(crc, &(pattern[i * 8 + j]), 1); } } /* Finally, invert the result once to get the correct data */ crc = ~crc; - return bit_reverse(crc); + return bitreverse(crc) >> 16; } /** diff -puN drivers/net/Kconfig~via-velocity-110 drivers/net/Kconfig --- linux-2.6.7/drivers/net/Kconfig~via-velocity-110 2004-06-30 22:31:05.000000000 +0200 +++ linux-2.6.7-fr/drivers/net/Kconfig 2004-06-30 22:31:05.000000000 +0200 @@ -1711,6 +1711,7 @@ config VIA_VELOCITY tristate "VIA Velocity support" depends on NET_PCI && PCI select CRC32 + select CRC16 select MII help If you have a VIA "Velocity" based network card say Y here. _ From jgarzik@pobox.com Wed Jun 30 13:40:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 13:40:48 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UKeZgi023464 for ; Wed, 30 Jun 2004 13:40:35 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bflsg-00078w-4e; Wed, 30 Jun 2004 21:40:34 +0100 Message-ID: <40E32535.30807@pobox.com> Date: Wed, 30 Jun 2004 16:40:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] get rid of warnings from 8139too driver References: <20040622135122.05be2be1@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622135122.05be2be1@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6467 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: 237 Lines: 10 Stephen Hemminger wrote: > Get rid of sparse warnings from 8139too driver. > * move start_thread which was inline into the open routine (only place called). as mentioned by Francois, I prefer the code separate, for clarity. Jeff From davem@redhat.com Wed Jun 30 14:43:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 14:43:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5ULhXgi028568 for ; Wed, 30 Jun 2004 14:43:34 -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 i5ULhCe1029889; Wed, 30 Jun 2004 17:43: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 i5ULhC012616; Wed, 30 Jun 2004 17:43: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 i5ULgjhA029890; Wed, 30 Jun 2004 17:42:46 -0400 Date: Wed, 30 Jun 2004 14:42:30 -0700 From: "David S. Miller" To: James Morris Cc: netfilter-devel@lists.netfilter.org, laforge@netfilter.org, netdev@oss.sgi.com, arjanv@redhat.com, kuznet@ms2.inr.ac.ru Subject: Re: Remote DoS vulnerability in Linux kernel 2.6.x (fwd) Message-Id: <20040630144230.1d52864b.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: 6468 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: 528 Lines: 12 On Wed, 30 Jun 2004 15:11:25 -0400 (EDT) James Morris wrote: > FYI, I have audited options parsing code in TCP, IPv4 input and Netfilter > for any similar problems and not found any. Further review would be > useful (I have not looked at the IPv6 header parsing for example). I can't find any other cases. This bug only came up because up the huge change Rusty and Harald did to make these modules not access the SKB header data directly, and instead to use local on-stack copies and skb_copy_bits(). From davem@redhat.com Wed Jun 30 15:39:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 15:39:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5UMdrgi030132 for ; Wed, 30 Jun 2004 15:39:54 -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 i5UMame1010762; Wed, 30 Jun 2004 18:36:48 -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 i5UMal026663; Wed, 30 Jun 2004 18:36: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 i5UMaLUc023107; Wed, 30 Jun 2004 18:36:22 -0400 Date: Wed, 30 Jun 2004 15:36:06 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-Id: <20040630153606.3493581b.davem@redhat.com> In-Reply-To: <20040630124050.GA1619@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> <20040630120045.GA7973@ms2.inr.ac.ru> <20040630120828.GA31498@gondor.apana.org.au> <20040630121420.GA8183@ms2.inr.ac.ru> <20040630124050.GA1619@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: 6469 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 Why don't you combine the two "ERR_PTR(-ECONNREFUSED)" tests into one test like: if ((nlk->pid == 0 && !nlk->data_ready) || (sock->sk_state == NELTINK_CONNECTED && nlk->dst_pid != nlk_sk(ssk)->pid)) { sock_put(sock); return ERR_PTR(-ECONNREFUSED); } so we don't have two copies of the "sock_put(); return ERR_PTR()" thing emitted by the compiler? From herbert@gondor.apana.org.au Wed Jun 30 16:33:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 16:33:16 -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.12.10/8.12.9) with SMTP id i5UNX9gi002157 for ; Wed, 30 Jun 2004 16:33: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 1Bfo5r-0007FA-00; Thu, 01 Jul 2004 09:02:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bfo5L-0001bI-00; Thu, 01 Jul 2004 09:01:47 +1000 Date: Thu, 1 Jul 2004 09:01:47 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-ID: <20040630230147.GA6136@gondor.apana.org.au> References: <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> <20040630120045.GA7973@ms2.inr.ac.ru> <20040630120828.GA31498@gondor.apana.org.au> <20040630121420.GA8183@ms2.inr.ac.ru> <20040630124050.GA1619@gondor.apana.org.au> <20040630153606.3493581b.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20040630153606.3493581b.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6470 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 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 30, 2004 at 03:36:06PM -0700, David S. Miller wrote: > > Why don't you combine the two "ERR_PTR(-ECONNREFUSED)" tests > into one test like: > > if ((nlk->pid == 0 && !nlk->data_ready) || > (sock->sk_state == NELTINK_CONNECTED && > nlk->dst_pid != nlk_sk(ssk)->pid)) { > sock_put(sock); > return ERR_PTR(-ECONNREFUSED); > } > > so we don't have two copies of the "sock_put(); return ERR_PTR()" > thing emitted by the compiler? Well at least under i386, gcc (3.3.4) is smart enough to merge these common exit paths. But yes we could merge them. What about the following incremental patch? -- 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 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- work-2.6/net/netlink/af_netlink.c.orig 2004-07-01 08:56:55.000000000 +1000 +++ work-2.6/net/netlink/af_netlink.c 2004-07-01 08:59:14.000000000 +1000 @@ -425,21 +425,23 @@ sock = netlink_lookup(protocol, pid); if (!sock) - return ERR_PTR(-ECONNREFUSED); + goto err; /* Don't bother queuing skb if kernel socket has no input function */ nlk = nlk_sk(sock); - if (nlk->pid == 0 && !nlk->data_ready) { - sock_put(sock); - return ERR_PTR(-ECONNREFUSED); - } + if (nlk->pid == 0 && !nlk->data_ready) + goto err_sock; if (sock->sk_state == NETLINK_CONNECTED && - nlk->dst_pid != nlk_sk(ssk)->pid) { - sock_put(sock); - return ERR_PTR(-ECONNREFUSED); - } + nlk->dst_pid != nlk_sk(ssk)->pid) + goto err_sock; + return sock; + +err_sock: + sock_put(sock); +err: + return ERR_PTR(-ECONNREFUSED); } struct sock *netlink_getsockbyfilp(struct file *filp) --8t9RHnE3ZwKMSgU+-- From rusty@rustcorp.com.au Wed Jun 30 18:13:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 18:13:20 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i611DGgi006556 for ; Wed, 30 Jun 2004 18:13:17 -0700 Received: from sd0208e0 (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id i611CT8o086082; Thu, 1 Jul 2004 11:12:34 +1000 Received: from ozlabs.au.ibm.com (haven.au.ibm.com [9.190.164.82]) by sd0208e0 (8.12.10/NCO/VER6.6) with ESMTP id i611Du3Z078654; Thu, 1 Jul 2004 11:13:57 +1000 Received: from bach.ozlabs.ibm.com (bach.ozlabs.ibm.com [10.61.2.150]) by ozlabs.au.ibm.com (Postfix) with ESMTP id E723C17DD8; Thu, 1 Jul 2004 11:13:01 +1000 (EST) Subject: Re: A problem with a large static arp table From: Rusty Russell To: Roman Zagustin Cc: netdev@oss.sgi.com In-Reply-To: <1835705734.20040630181449@techas.lt> References: <1835705734.20040630181449@techas.lt> Content-Type: text/plain Message-Id: <1088644366.8180.2.camel@bach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 01 Jul 2004 11:12:46 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 6471 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 On Thu, 2004-07-01 at 01:14, Roman Zagustin wrote: > Hello! Hi, Not really my area; pinging netdev to see if they can help. > I have a router with >800 static ip/mac records. > It does not work :( > With small table it is fine. > The kernel is 2.6 (tried with different patches and versions > 2.4 - the same) > > Just for example(real): > > root@stargate:/proc/sys/net/ipv4/neigh/default# arp -n|grep 172.16.3.230 > 172.16.3.230 ether 00:50:04:6C:50:9E CM eth3 > root@stargate:/proc/sys/net/ipv4/neigh/default# > root@stargate:/proc/sys/net/ipv4/neigh/default# tcpdump -i eth3 host 172.16.3.230 -e > tcpdump: listening on eth3 > 15:38:10.660144 0:6:29:ee:c3:d8 0:2:b3:b4:34:e2 ip 448: 172.16.3.230.1060 > medium.cs.microlink.lt.http: P 1268207798:1268208192(394) ack 3537529644 win 64240 (DF) > 15:38:10.674698 0:6:29:ee:c3:d8 0:2:b3:b4:34:e2 ip 453: 172.16.3.230.1077 > medium.cs.microlink.lt.http: P 1279539300:1279539699(399) ack 2683450794 win 63095 (DF) > > There are no errors/warnings in the log files about neighbour table. > > >From the server I can't ping the 172.16.3.230, but it can ping the > server. In general, server do not check the ip/mac table at all > when forwarding received packets. > > I don't know where is the problem :( -- Anyone who quotes me in their signature is an idiot -- Rusty Russell From jmorris@redhat.com Wed Jun 30 18:26:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 18:26:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i611Qngi008019 for ; Wed, 30 Jun 2004 18:26:49 -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 i5UJBVe1022456; Wed, 30 Jun 2004 15:11:31 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5UJBS027488; Wed, 30 Jun 2004 15:11:29 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i5UJBP8j017846; Wed, 30 Jun 2004 15:11:25 -0400 Date: Wed, 30 Jun 2004 15:11:25 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: netfilter-devel@lists.netfilter.org, Harald Welte cc: netdev@oss.sgi.com, Arjan van de Ven , "David S. Miller" , , =?iso-2022-jp?Q?YOSHIFUJI_Hideaki_=2F_=1B$B5HF#1QL=40=1B=28B?= Subject: Re: Remote DoS vulnerability in Linux kernel 2.6.x (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6472 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 FYI, I have audited options parsing code in TCP, IPv4 input and Netfilter for any similar problems and not found any. Further review would be useful (I have not looked at the IPv6 header parsing for example). On Wed, 30 Jun 2004, James Morris wrote: > ---------- Forwarded message ---------- > Date: Wed, 30 Jun 2004 12:57:17 +0200 > From: Adam Osuchowski > To: bugtraq@securityfocus.com > Subject: Remote DoS vulnerability in Linux kernel 2.6.x > > 1. Overview > ----------- > > There is a remotely exploitable bug in all Linux kernel 2.6 series due to > using incorrect variable type. Vulnerability is connected to netfilter > subsystem and may cause DoS. It's disclosed only when using iptables with > rules matching TCP options (i.e. --tcp-option). There is no difference > what action is taking up by matching rule. > > Vulnerability was detected on i386 architecture. The other ones weren't tested > but it seems to be vulnerable too. > > 2. Details > ---------- > > Problem lies in tcp_find_option() function (net/ipv4/netfilter/ip_tables.c). > There is local array `opt' defined as: > > char opt[60 - sizeof(struct tcphdr)]; > > which contains TCP options extracted from packet. Function mentioned above > searches for specified option in this array. > > Options in TCP packet, with some exceptions, are organized in the following > way: > > Octet no. Length Field > ----------------------------- > 0 1 Opcode > 1 1 Length of all option (N + 2) > 2 N Params > > > The function iterates over options in array: > > for (i = 0; i < optlen; ) { > if (opt[i] == option) return !invert; > if (opt[i] < 2) i++; > else i += opt[i+1]?:1; > } > > moving counter by the option length. > > But, in case the `length' value is greater than 127, the value of this octet > in `opt' is implicitly casted to char, which results in negative number and > the loop counter moving back. In some cases it is possible, that counter > cycles throught the contents of this array infinitely. > > 3. Impact > --------- > > After sending one suitably prepared TCP packet to victim host, kernel goes > into infinite loop consuming all CPU resources, rendering the box > unresponsable. Of course, there is no need to have a shell access to attacked > host. > > 4. Exploitation > --------------- > > Example of packet-of-death: > > 0x0000: 4500 0030 1234 4000 ff06 e83f c0a8 0001 > 0x0010: c0a8 0002 0400 1000 0000 0064 0000 0064 > 0x0020: 7000 0fa0 dc6a 0000 0204 05b4 0101 04fd > > 5. Fix > ------ > > There is only need to change type of `opt' array from signed char to unsigned > (or, better to u_int8_t) as it was defined in 2.4 kernel or prior to version > 1.16 of net/ipv4/netfilter/ip_tables.c file. > > --- net/ipv4/netfilter/ip_tables.c.orig 2004-04-04 05:36:47.000000000 +0200 > +++ net/ipv4/netfilter/ip_tables.c 2004-06-24 21:24:26.000000000 +0200 > @@ -1461,7 +1461,7 @@ > int *hotdrop) > { > /* tcp.doff is only 4 bits, ie. max 15 * 4 bytes */ > - char opt[60 - sizeof(struct tcphdr)]; > + u_int8_t opt[60 - sizeof(struct tcphdr)]; > unsigned int i; > > duprintf("tcp_match: finding option\n"); > > 6. Credits > ---------- > > Vulnerability was discovered, identified and fixed by Adam Osuchowski > and Tomasz Dubinski. > > -- James Morris From jgarzik@pobox.com Wed Jun 30 20:19:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:19:48 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i613Jjgi013680 for ; Wed, 30 Jun 2004 20:19:46 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bfs6y-00054R-JZ; Thu, 01 Jul 2004 04:19:44 +0100 Message-ID: <40E382BF.7060904@pobox.com> Date: Wed, 30 Jun 2004 23:19:27 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/6 Linux-2.6.7-bk13] prism54 cleanup functions References: <200406301939.51868.margitsw@t-online.de> In-Reply-To: <200406301939.51868.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6473 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 patches 1-6 From jgarzik@pobox.com Wed Jun 30 20:21:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:21: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.12.10/8.12.9) with SMTP id i613LMgi013919 for ; Wed, 30 Jun 2004 20:21:22 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bfs8V-00055n-Eq; Thu, 01 Jul 2004 04:21:19 +0100 Message-ID: <40E38323.1070702@pobox.com> Date: Wed, 30 Jun 2004 23:21:07 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com, psimmons@flash.net Subject: Re: [PATCH 5 2.6.7-bk6] pcnet32: Add HomePNA parameter for 79C978. References: <200406231816.i5NIG5J16003@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200406231816.i5NIG5J16003@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6474 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 patches #4-7 From jgarzik@pobox.com Wed Jun 30 20:23:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:23:43 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i613Nfgi014331 for ; Wed, 30 Jun 2004 20:23:42 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsAm-00057f-KY; Thu, 01 Jul 2004 04:23:40 +0100 Message-ID: <40E383B0.1020207@pobox.com> Date: Wed, 30 Jun 2004 23:23:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: netdev@oss.sgi.com Subject: Re: [PATCH] natsemi 1: switch to netdev_priv() References: <40DC8BC3.2000401@colorfullife.com> In-Reply-To: <40DC8BC3.2000401@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6475 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 patches 1 and 2 look OK, but don't apply cleanly against mainline. I'll try against -netdev in a few days From jgarzik@pobox.com Wed Jun 30 20:25:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:25: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.12.10/8.12.9) with SMTP id i613P2gi014653 for ; Wed, 30 Jun 2004 20:25:02 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsC5-00058T-CY; Thu, 01 Jul 2004 04:25:01 +0100 Message-ID: <40E38401.3000209@pobox.com> Date: Wed, 30 Jun 2004 23:24:49 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] (1/3) skfp - cleanup is_XXX functions References: <20040622142052.7b9af6bc@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622142052.7b9af6bc@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6476 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 From jgarzik@pobox.com Wed Jun 30 20:25:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:25: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.12.10/8.12.9) with SMTP id i613P7gi014680 for ; Wed, 30 Jun 2004 20:25:07 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsCA-00058X-Ew; Thu, 01 Jul 2004 04:25:06 +0100 Message-ID: <40E38406.5030200@pobox.com> Date: Wed, 30 Jun 2004 23:24:54 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] (2/3) skfp -- sparse __user annotation References: <20040622142148.287d402d@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622142148.287d402d@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6477 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 From jgarzik@pobox.com Wed Jun 30 20:27:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20: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.12.10/8.12.9) with SMTP id i613RCgi015270 for ; Wed, 30 Jun 2004 20:27:13 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsEC-0005Ae-3J; Thu, 01 Jul 2004 04:27:12 +0100 Message-ID: <40E38484.5000608@pobox.com> Date: Wed, 30 Jun 2004 23:27:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] get rid of warnings about #if DEBUG References: <20040622135253.43a9acde@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622135253.43a9acde@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6479 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 From jgarzik@pobox.com Wed Jun 30 20:27:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:27: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.12.10/8.12.9) with SMTP id i613R7gi015246 for ; Wed, 30 Jun 2004 20:27:07 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsE6-0005AU-Ee; Thu, 01 Jul 2004 04:27:06 +0100 Message-ID: <40E3847E.3040906@pobox.com> Date: Wed, 30 Jun 2004 23:26:54 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] dgrs -- cleanup warnings References: <20040622142722.343300b3@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622142722.343300b3@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6478 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 bounced: OK but patch(1) rejected. please rediff and resubmit. From jgarzik@pobox.com Wed Jun 30 20:27:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:27: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.12.10/8.12.9) with SMTP id i613RIgi015357 for ; Wed, 30 Jun 2004 20:27:19 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsEI-0005Ai-0g; Thu, 01 Jul 2004 04:27:18 +0100 Message-ID: <40E3848A.4030509@pobox.com> Date: Wed, 30 Jun 2004 23:27:06 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] get rid of __OPTIMIZE__ requirement in net drivers References: <20040622113052.1ef2cb7b@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622113052.1ef2cb7b@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6480 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 From jgarzik@pobox.com Wed Jun 30 20:29:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:29: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.12.10/8.12.9) with SMTP id i613TAgi016162 for ; Wed, 30 Jun 2004 20:29:11 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsG5-0005Bn-P8; Thu, 01 Jul 2004 04:29:09 +0100 Message-ID: <40E384F9.7090108@pobox.com> Date: Wed, 30 Jun 2004 23:28:57 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-mm3 1/1] via-velocity: use common crc16 code for WOL References: <20040630223346.A23520@electric-eye.fr.zoreil.com> In-Reply-To: <20040630223346.A23520@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6481 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 patch OK but rejected against mainline From jgarzik@pobox.com Wed Jun 30 20:40:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:40: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.12.10/8.12.9) with SMTP id i613e3gi016662 for ; Wed, 30 Jun 2004 20:40:04 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsQc-0005Kz-Mw; Thu, 01 Jul 2004 04:40:03 +0100 Message-ID: <40E38786.9010600@pobox.com> Date: Wed, 30 Jun 2004 23:39:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] skfddi - fix warning References: <20040622105146.56e92d80@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622105146.56e92d80@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6482 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 From jgarzik@pobox.com Wed Jun 30 20:40:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:40:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i613eigi016826 for ; Wed, 30 Jun 2004 20:40:45 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BfsRH-0005Lj-Vy; Thu, 01 Jul 2004 04:40:44 +0100 Message-ID: <40E387B0.5040404@pobox.com> Date: Wed, 30 Jun 2004 23:40:32 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] skfddi - cleanup local and dead functions References: <20040622104953.10a5930e@dell_ss3.pdx.osdl.net> In-Reply-To: <20040622104953.10a5930e@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6483 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 From mcgrof@studorgs.rutgers.edu Wed Jun 30 20:45:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 20:45:41 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i613jcgi017313 for ; Wed, 30 Jun 2004 20:45:39 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 3316EF9D9E; Wed, 30 Jun 2004 23:45:38 -0400 (EDT) Date: Wed, 30 Jun 2004 23:45:38 -0400 To: Margit Schubert-While Cc: Jeff Garzik , netdev@oss.sgi.com, prism54@prism54.org Message-ID: <20040701034538.GJ14482@ruslug.rutgers.edu> Mail-Followup-To: Margit Schubert-While , Jeff Garzik , netdev@oss.sgi.com, prism54@prism54.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 6484 Subject: (no subject) 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 prism54-devel@prism54.org Bcc: Subject: Re: [PATCH 1/6 Linux-2.6.7-bk13] prism54 cleanup functions Reply-To: In-Reply-To: <40E382BF.7060904@pobox.com> X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group On Wed, Jun 30, 2004 at 11:19:27PM -0400, Jeff Garzik wrote: > applied patches 1-6 > Margit, please commit to prism54 CVS :) Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From garzik@havoc.gtf.org Wed Jun 30 21:25:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 21:25:19 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i614P2gi018508 for ; Wed, 30 Jun 2004 21:25:02 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id A91FA7640 for ; Wed, 30 Jun 2004 23:54:02 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i613s2E0025569 for netdev@oss.sgi.com; Wed, 30 Jun 2004 23:54:02 -0400 Date: Wed, 30 Jun 2004 23:54:02 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x net driver updates Message-ID: <20040701035402.GA25546@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: 6485 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 This is what I just sent to Andrew and Linus. BK users may do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/arm/smc91x.c | 2171 ------------------------- drivers/net/arm/smc91x.h | 829 --------- drivers/net/3c59x.c | 6 drivers/net/Kconfig | 25 drivers/net/Makefile | 2 drivers/net/acenic.c | 12 drivers/net/arm/Kconfig | 18 drivers/net/arm/Makefile | 1 drivers/net/eepro100.c | 6 drivers/net/epic100.c | 6 drivers/net/fec_8xx/Kconfig | 14 drivers/net/fec_8xx/Makefile | 12 drivers/net/fec_8xx/fec_8xx-netta.c | 153 + drivers/net/fec_8xx/fec_8xx.h | 218 ++ drivers/net/fec_8xx/fec_main.c | 1275 +++++++++++++++ drivers/net/fec_8xx/fec_mii.c | 380 ++++ drivers/net/ixgb/ixgb.h | 2 drivers/net/natsemi.c | 6 drivers/net/pcmcia/3c574_cs.c | 11 drivers/net/pcmcia/3c589_cs.c | 9 drivers/net/pcmcia/axnet_cs.c | 9 drivers/net/pcmcia/com20020_cs.c | 32 drivers/net/pcmcia/fmvj18x_cs.c | 9 drivers/net/pcmcia/ibmtr_cs.c | 1 drivers/net/pcmcia/nmclan_cs.c | 9 drivers/net/pcmcia/pcnet_cs.c | 9 drivers/net/pcmcia/smc91c92_cs.c | 9 drivers/net/pcmcia/xirc2ps_cs.c | 9 drivers/net/pcnet32.c | 61 drivers/net/sb1250-mac.c | 6 drivers/net/sk98lin/h/skdrv1st.h | 6 drivers/net/skfp/fplustm.c | 28 drivers/net/skfp/h/cmtdef.h | 4 drivers/net/skfp/h/targetos.h | 2 drivers/net/skfp/skfddi.c | 5 drivers/net/skfp/smt.c | 86 - drivers/net/smc91x.c | 2173 ++++++++++++++++++++++++++ drivers/net/smc91x.h | 866 ++++++++++ drivers/net/sundance.c | 9 drivers/net/tulip/winbond-840.c | 9 drivers/net/typhoon.c | 6 drivers/net/via-rhine.c | 6 drivers/net/wan/sbni.h | 2 drivers/net/wireless/prism54/isl_ioctl.c | 4 drivers/net/wireless/prism54/islpci_dev.c | 7 drivers/net/wireless/prism54/islpci_dev.h | 2 drivers/net/wireless/prism54/islpci_eth.c | 8 drivers/net/wireless/prism54/islpci_hotplug.c | 124 + drivers/net/wireless/prism54/islpci_mgt.h | 3 drivers/net/wireless/prism54/oid_mgt.c | 4 drivers/net/yellowfin.c | 8 51 files changed, 5374 insertions(+), 3298 deletions(-) through these ChangeSets: (04/06/30 1.1805) [netdrvr] add fec_8xx to Makefile (04/06/30 1.1804) [PATCH] skfddi - cleanup local and dead functions Cleanup the SK Fddi driver a little more. Mark some functions as static, and eliminate (or comment out) some that are defined but never used. Signed-off-by: Stephen Hemminger (04/06/30 1.1803) [PATCH] skfddi - fix warning The conversion to ANSI, caused a warning because the mulitcast code needs a cast. dmi->dmi_addr is a u8 array, and fddi_addr is just a wrapper around a u8 array. Signed-off-by: Stephen Hemminger (04/06/30 1.1802) [PATCH] add new fec_8xx network driver (04/06/30 1.1801) [PATCH] Patch 2/2 enable smc91x enet driver for use by PPC Hi, Patch 2 of 2 to enable the smc91x driver to be used by the IBM Redwood5 and Redwood6 boards. Enable smc91x driver to support IBM Redwood5 and Redwood6 boards Signed-off-by: Dale Farnsworth (04/06/30 1.1800) [PATCH] Patch 1/2 enable smc91x enet driver for use by PPC Hi, Patch 1 of 2 to enable the smc91x driver to be used by the IBM Redwood5 and Redwood6 boards. Move drivers/net/arm/smc91x.[ch] to drivers/net Signed-off-by: Dale Farnsworth (04/06/30 1.1799) [PATCH] PCMCIA net device unplugging ordering fix This is a rather old patch which re-orders the teardown of PCMCIA network devices. Current device drivers remove the IO mappings, interrupts, and free any PCMCIA windows before they unregister themselves from the network layer. This patch ensures that we first unregister from the network layer before performing any teardown of resources or windows. Note: the only card which has been tested in this patch is pcnet_cs. (04/06/30 1.1798) [PATCH] get rid of __OPTIMIZE__ requirement in net drivers Several network drivers have checks that they are only built with -O. This breaks checking with sparse and other tools, and seems like a holdover from when drivers were built out of tree and the kernel build system was less stable. This patch gets rid of these. Signed-off-by: Stephen Hemminger (04/06/30 1.1797) [PATCH] [sparse] get rid of warnings about #if DEBUG Several drivers use '#if DEBUG' which is a warning under the sparse checker. Signed-off-by: Stephen Hemminger (04/06/30 1.1796) [PATCH] (2/3) skfp -- sparse __user annotation Add __user annotation to the device specific ioctl. (04/06/30 1.1795) [PATCH] (1/3) skfp - cleanup is_XXX functions This started out from sparse warnings about calling with fddi_broadcast that is declared const. This fixes that and gets rid of some of the namespace pollution of this driver by moving the predicate function is_individual, is_broadcast, ... as inline's in the one file that uses them. Signed-off-by: Stephen Hemminger (04/06/30 1.1794) [PATCH] net/ne2.c needs MCA_LEGACY From: "Luiz Fernando N. Capitulino" drivers/net/ne2.c does not compile without CONFIG_MCA_LEGACY set. As CONFIG_MCA_LEGACY depends on CONFIG_MCA, we can use only CONFIG_MCA_LEGACY, insteed of "MCA && MCA_LEGACY". Signed-off-by: Luiz Capitulino Signed-off-by: Andrew Morton (04/06/30 1.1793) [PATCH] net/at1700.c depends on MCA_LEGACY From: "Luiz Fernando N. Capitulino" drivers/net/at1700.c does not compile without CONFIG_MCA_LEGACY set. As CONFIG_MCA_LEGACY depends on CONFIG_MCA, we can use only CONFIG_MCA_LEGACY, insteed of "MCA && MCA_LEGACY". Signed-off-by: Luiz Capitulino Signed-off-by: Andrew Morton (04/06/30 1.1792) [PATCH] pcnet32: change to use module_param Change the pcnet32 driver to use module_param and module_param_array. (04/06/30 1.1791) [PATCH] pcnet32: correctly program bcr32. The pcnet32 driver was not correctly enabling MII autonegotiation after booting when ppc firmware forced the speed/duplex mode of the chip. After several conversations with AMD this patch corrects the problem. I have tested this on hardware I have available (ia32 and ppc64) but I would like wider audience testing of this patch. Signed-off-by: Don Fry (04/06/30 1.1790) [PATCH] pcnet32: Add HomePNA parameter for 79C978. This patch adds a module parameter to select HomePNA mode of operation for the 79C978 version of the pcnet32. Tested ia32 and ppc64. signed-off-by: Patrick Simmons signed-off-by: Don Fry (04/06/30 1.1789) [PATCH] pcnet32: acknowledge all interrupts early. A recent change I made broke pcnet32 in a way that allowed real hardware to work, but broke VMWare. This patch acknowledges all interrupts early in the pcnet32_interrupt while loop. Without this patch on real hardware the first transmit operation would clear the 'init' interrupt, but in VMWare it would rain interrupts. Keith Moore did more testing for me on VMWare and I did a better job testing on hardware. Petr Vandrovec correctly pointed out the source of the problem on lkml. This patch is not needed for 2.4.27-rc1 unless my patch labeled "pcnet32: recover after rx hang" is applied (which it has not). signed-off-by: Don Fry (04/06/30 1.1788) [PATCH] prism54 use set_pci_mwi() 2004-06-28 Margit Schubert-While * Use set_pci_mwi() (04/06/30 1.1787) [PATCH] prism54 remove prog reg poke 2004-06-28 Margit Schubert-While * Don't poke around in the timeout registers (04/06/30 1.1786) [PATCH] prism54 device list cleanup 2004-06-28 Margit Schubert-While * Clean up the device table (04/06/30 1.1785) [PATCH] prism54 fix unlikely 2004-06-28 Margit Schubert-While * Fix a thinko by me (04/06/30 1.1784) [PATCH] prism54 missing error check 2004-06-28 Margit Schubert-While * Missing error check after dev_alloc_skb (04/06/30 1.1783) [PATCH] prism54 cleanup functions 2004-06-28 Margit Schubert-While * Clean up function definitions (missing static, extraneous inline) From margitsw@t-online.de Wed Jun 30 21:38:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Jun 2004 21:38:59 -0700 (PDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i614csgi019019 for ; Wed, 30 Jun 2004 21:38:55 -0700 Received: from fwd07.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1BfjAI-0003Nu-02; Wed, 30 Jun 2004 19:46:34 +0200 Received: from roglap.local (Ew8LC4ZdZeH1C95lkE5qzbc-gq7uk4P7AYkRXN9mcE3zDeakzS+UYA@[217.226.122.65]) by fwd07.sul.t-online.com with esmtp id 1BfjA0-1nhypU0; Wed, 30 Jun 2004 19:46:16 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 1/6 Linux-2.6.7-bk13] prism54 cleanup functions Date: Wed, 30 Jun 2004 19:39:51 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_nrv4AA/yDaRfJpt" Message-Id: <200406301939.51868.margitsw@t-online.de> X-Seen: false X-ID: Ew8LC4ZdZeH1C95lkE5qzbc-gq7uk4P7AYkRXN9mcE3zDeakzS+UYA X-archive-position: 6486 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=_nrv4AA/yDaRfJpt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-06-28 Margit Schubert-While * Clean up function definitions (missing static, extraneous inline) --Boundary-00=_nrv4AA/yDaRfJpt Content-Type: text/x-diff; charset="us-ascii"; name="01_function_clean.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="01_function_clean.patch" diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.7-02/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.7-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.7-02/drivers/net/wireless/prism54/isl_ioctl.c 2004-06-25 20:08:48.000000000 +0200 @@ -577,7 +577,7 @@ * the "Aironet driver for 4500 and 4800 series cards" (GPL) */ -inline char * +static char * prism54_translate_bss(struct net_device *ndev, char *current_ev, char *end_buf, struct obj_bss *bss, char noise) { @@ -1502,7 +1502,7 @@ /* Translate a TRAP oid into a wireless event. Called in islpci_mgt_receive. */ -static inline void +static void format_event(islpci_private *priv, char *dest, const char *str, const struct obj_mlme *mlme, u16 *length, int error) { diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.7-02/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.7-01/drivers/net/wireless/prism54/islpci_dev.c 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.7-02/drivers/net/wireless/prism54/islpci_dev.c 2004-06-25 20:08:48.000000000 +0200 @@ -41,6 +41,9 @@ #define ISL3877_IMAGE_FILE "isl3877" #define ISL3890_IMAGE_FILE "isl3890" +static int prism54_bring_down(islpci_private *); +static int islpci_alloc_memory(islpci_private *); + /* Temporary dummy MAC address to use until firmware is loaded. * The idea there is that some tools (such as nameif) may query * the MAC address before the netdev is 'open'. By using a valid @@ -390,7 +393,7 @@ return prism54_bring_down(priv); } -int +static int prism54_bring_down(islpci_private *priv) { void *device_base = priv->device_base; @@ -601,7 +604,7 @@ /****************************************************************************** Network device configuration functions ******************************************************************************/ -int +static int islpci_alloc_memory(islpci_private *priv) { int counter; diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/islpci_dev.h linux-2.6.7-02/drivers/net/wireless/prism54/islpci_dev.h --- linux-2.6.7-01/drivers/net/wireless/prism54/islpci_dev.h 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.7-02/drivers/net/wireless/prism54/islpci_dev.h 2004-06-25 20:08:48.000000000 +0200 @@ -210,8 +210,6 @@ struct net_device_stats *islpci_statistics(struct net_device *); -int prism54_bring_down(islpci_private *); -int islpci_alloc_memory(islpci_private *); int islpci_free_memory(islpci_private *); struct net_device *islpci_setup(struct pci_dev *); #endif /* _ISLPCI_DEV_H */ diff -Naur linux-2.6.7-01/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.7-02/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.7-01/drivers/net/wireless/prism54/oid_mgt.c 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.7-02/drivers/net/wireless/prism54/oid_mgt.c 2004-06-25 20:08:48.000000000 +0200 @@ -675,7 +675,7 @@ /* This will tell you if you are allowed to answer a mlme(ex) request .*/ -inline int +int mgt_mlme_answer(islpci_private *priv) { u32 mlmeautolevel; @@ -692,7 +692,7 @@ (mlmeautolevel >= DOT11_MLME_INTERMEDIATE)); } -inline enum oid_num_t +enum oid_num_t mgt_oidtonum(u32 oid) { int i; --Boundary-00=_nrv4AA/yDaRfJpt--