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 R2 can 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 S and 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 10 is 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 TCP throughput _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 high for 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 all cases, 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" of 100-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 TCP throughput _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 100 packets @ 100 Mb/s (and lived approximately happy @ > 10 Mb/s), but we'll soon see doom and gloom with this new and > brutal change to 1000 packets 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, Maxfeldstraße 5, 90409 Nürnberg, 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, Maxfeldstraße 5, 90409 Nürnberg, 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, Maxfeldstraße 5, 90409 Nürnberg, 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 bcm5700 driver 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 e100 assumes 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 Pádraig. 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. Pádraig 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. > > Pádraig 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 Pádraig. 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.odess