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.GA1607