From margitsw@t-online.de Fri Oct 1 01:28:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 01:28:59 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i918Sl34001160 for ; Fri, 1 Oct 2004 01:28:48 -0700 Received: from fwd08.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1CDIlu-0001TT-01; Fri, 01 Oct 2004 10:28:10 +0200 Received: from margit.t-online.de (Eq72tqZQYeFJSATDoI6WHGJ8lJbKO6salRcY6pGgjMmnF2ZtYJpI6M@[80.128.216.173]) by fwd08.sul.t-online.com with esmtp id 1CDIlk-1TXdRo0; Fri, 1 Oct 2004 10:28:00 +0200 Message-Id: <5.1.0.14.2.20041001084419.02570b18@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Oct 2004 09:04:27 +0200 To: Jeff Garzik From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() Cc: nacc@us.ibm.com, hvr@gnu.org, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, prism54-devel@prism54.org, netdev@oss.sgi.com In-Reply-To: <415CD9D9.2000607@pobox.com> References: <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> <20040923221303.GB13244@us.ibm.com> <20040923221303.GB13244@us.ibm.com> <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ID: Eq72tqZQYeFJSATDoI6WHGJ8lJbKO6salRcY6pGgjMmnF2ZtYJpI6M X-TOI-MSGID: ba701764-ae02-4cb2-8a64-3c7b741aec8c X-archive-position: 9760 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 At 00:15 01.10.2004 -0400, Jeff scribeth: >I would rather see an msleep implementation in 2.4.x... Hear, hear. And can we PLEASE have a "#define HAVE_MSLEEP" in delay.h ?!!! (2.4. AND 2.6) Margit From laforge@netfilter.org Fri Oct 1 02:02:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 02:02:45 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9192dsY001982 for ; Fri, 1 Oct 2004 02:02:39 -0700 Received: from dsl-213-023-154-116.arcor-ip.net ([213.23.154.116] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CDJJ1-0006Kj-CT; Fri, 01 Oct 2004 11:02:23 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CDJIz-00077K-Hi; Fri, 01 Oct 2004 11:02:21 +0200 Date: Fri, 1 Oct 2004 11:02:21 +0200 From: Harald Welte To: Yasuyuki Kozakai Cc: kaber@trash.net, okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi-core@linux-ipv6.org Subject: When to submit to which list (was Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type) Message-ID: <20041001090221.GO1860@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Yasuyuki Kozakai , kaber@trash.net, okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi-core@linux-ipv6.org References: <200409301244.i8UCid17009482@toshiba.co.jp> <415C1CC9.2090604@trash.net> <200410010019.i910JlZY002193@toshiba.co.jp> <200410010509.i9159Cg2021037@toshiba.co.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/T+UM55GOh1Yge7W" Content-Disposition: inline In-Reply-To: <200410010509.i9159Cg2021037@toshiba.co.jp> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --/T+UM55GOh1Yge7W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2004 at 02:09:10PM +0900, Yasuyuki Kozakai wrote: > # Sometimes I confuse I should send patches to netdev, or send them to > # netfilter-devel and core team of netfilter review/send it to netdev. I don't know what Patrick told you, but I think as a general rule of thumb, all netfilter-related patches should go to netfilter-devel first. Patrick or I will then push them upstream to DaveM (most times with Cc to netdev). For urgent/critical bugfixes (that are not too complex), I am ok if netfilter-devel is bypassed and you submit it to netdev/davem immediately. Pragmatically speaking, Patrick or me will read your emails on either list - but a number of other netfilter developers is not following netdev, so you deprive them of the chance to give comments before it is submitted ;) Thanks! --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --/T+UM55GOh1Yge7W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBXR0dXaXGVTD0i/8RAlTsAJ9kMxhFyec9cXf20Z7dH4U+HotAlgCePMol Fs2rfgLUkx5j3K3s7G1oDbQ= =ng6f -----END PGP SIGNATURE----- --/T+UM55GOh1Yge7W-- From yasuyuki.kozakai@toshiba.co.jp Fri Oct 1 02:33:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 02:33:48 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i919Xc4i003075 for ; Fri, 1 Oct 2004 02:33:39 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i919X6bv004952; Fri, 1 Oct 2004 18:33:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i919X6J5003553; Fri, 1 Oct 2004 18:33:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id UAA03552 ; Fri, 1 Oct 2004 18:33:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id SAA12611; Fri, 1 Oct 2004 18:33:05 +0900 (JST) Received: by toshiba.co.jp id i919X4R9010911; Fri, 1 Oct 2004 18:33:04 +0900 (JST) Date: Fri, 01 Oct 2004 18:33:02 +0900 (JST) Message-Id: <200410010933.i919X4R9010911@toshiba.co.jp> To: laforge@netfilter.org Cc: yasuyuki.kozakai@toshiba.co.jp, kaber@trash.net, okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi-core@linux-ipv6.org Subject: Re: When to submit to which list From: Yasuyuki Kozakai In-Reply-To: <20041001090221.GO1860@sunbeam.de.gnumonks.org> References: <200410010019.i910JlZY002193@toshiba.co.jp> <200410010509.i9159Cg2021037@toshiba.co.jp> <20041001090221.GO1860@sunbeam.de.gnumonks.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev OK, I'll send patches to netfilter-devel as ever. Thanks, ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project From: Harald Welte Date: Fri, 1 Oct 2004 11:02:21 +0200 > On Fri, Oct 01, 2004 at 02:09:10PM +0900, Yasuyuki Kozakai wrote: > > # Sometimes I confuse I should send patches to netdev, or send them to > > # netfilter-devel and core team of netfilter review/send it to netdev. > > I don't know what Patrick told you, but I think as a general rule of > thumb, all netfilter-related patches should go to netfilter-devel first. > Patrick or I will then push them upstream to DaveM (most times with Cc > to netdev). > > For urgent/critical bugfixes (that are not too complex), I am ok if > netfilter-devel is bypassed and you submit it to netdev/davem > immediately. > > Pragmatically speaking, Patrick or me will read your emails on either > list - but a number of other netfilter developers is not following > netdev, so you deprive them of the chance to give comments before it is > submitted ;) > > Thanks! > > -- > - Harald Welte http://www.netfilter.org/ > ============================================================================ > "Fragmentation is like classful addressing -- an interesting early > architectural error that shows how much experimentation was going > on while IP was being designed." -- Paul Vixie From ak@suse.de Fri Oct 1 03:11:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 03:11:51 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91ABhKB005813 for ; Fri, 1 Oct 2004 03:11:45 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 6B52ECB05CC; Fri, 1 Oct 2004 12:11:26 +0200 (CEST) Date: Fri, 1 Oct 2004 12:11:23 +0200 From: Andi Kleen To: "David S. Miller" Cc: netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-Id: <20041001121123.19511403.ak@suse.de> In-Reply-To: <20040930213221.06a3f5b3.davem@davemloft.net> References: <20040930213221.06a3f5b3.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, 30 Sep 2004 21:32:21 -0700 "David S. Miller" wrote: > > 1) Andi sees performance anomaly to 2.6.5 kernels. > Hopefully fixed by diff3 above, merely awaiting > retesting by him. Didn't fix the problem unfortunately, it's even a bit slower with TSO than the previous kernel I tested. The stretch acks are still quite visible, see http://www.firstfloor.org/~andi/tso-stretch-ack1.gz for the full log. I will try to do the ACK instrumentation on the receiver you suggested later, unfortunately have some other urgent things to do first. Do you want me to play with the new sysctl too? tcptrace output for the last run as overview: complete conn: yes first packet: Fri Oct 1 12:02:39.725840 2004 last packet: Fri Oct 1 12:02:49.729142 2004 elapsed time: 0:00:10.003302 total packets: 315102 filename: /tmp/LOG e->f: f->e: total packets: 298495 total packets: 16607 ack pkts sent: 298494 ack pkts sent: 16607 pure acks sent: 2 pure acks sent: 16605 unique bytes sent: 432215424 unique bytes sent: 0 actual data pkts: 298492 actual data pkts: 0 actual data bytes: 432215424 actual data bytes: 0 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 16715 pushed data pkts: 0 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 2 adv wind scale: 0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 0 bytes min segm size: 456 bytes min segm size: 0 bytes avg segm size: 1447 bytes avg segm size: 0 bytes max win adv: 5840 bytes max win adv: 63712 bytes min win adv: 5840 bytes min win adv: 5792 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 5840 bytes avg win adv: 63673 bytes initial window: 4344 bytes initial window: 0 bytes initial window: 3 pkts initial window: 0 pkts ttl stream length: 432215424 bytes ttl stream length: 0 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 423260664 bytes truncated data: 0 bytes truncated packets: 298492 pkts truncated packets: 0 pkts data xmit time: 10.003 secs data xmit time: 0.000 secs idletime max: 8.4 ms idletime max: 8.6 ms throughput: 43207275 Bps throughput: 0 Bps No SACKs etc. -Andi From ak@suse.de Fri Oct 1 03:23:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 03:23:38 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91ANRPx006257 for ; Fri, 1 Oct 2004 03:23:28 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id DB57ECB075C; Fri, 1 Oct 2004 12:23:09 +0200 (CEST) Date: Fri, 1 Oct 2004 12:23:06 +0200 From: Andi Kleen To: "David S. Miller" Cc: herbert@gondor.apana.org.au, jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20041001102306.GA4898@wotan.suse.de> References: <20040929162923.796d142e.davem@davemloft.net> <20040929170310.46c58095.davem@davemloft.net> <20040930001007.GB10496@gondor.apana.org.au> <20040930173439.3e0d2799.davem@davemloft.net> <20040930181248.48185e41.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040930181248.48185e41.davem@davemloft.net> X-archive-position: 9764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > With such small receive buffers, netperf simply can't clear > the receive queue fast enough when a burst of TSO created > frames come in. I increased the receive buffers on the target and the difference between TSO and non TSO is much less now (only 5MB/s instead of 20MB/s) Your theory seems to make some sense. -Andi From ak@suse.de Fri Oct 1 03:38:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 03:38:51 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91Aceql006711 for ; Fri, 1 Oct 2004 03:38:41 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 43E15CAC565; Fri, 1 Oct 2004 12:35:55 +0200 (CEST) Date: Fri, 1 Oct 2004 12:35:54 +0200 From: Andi Kleen To: "David S. Miller" Cc: herbert@gondor.apana.org.au, jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20041001103554.GB4898@wotan.suse.de> References: <20040929162923.796d142e.davem@davemloft.net> <20040929170310.46c58095.davem@davemloft.net> <20040930001007.GB10496@gondor.apana.org.au> <20040930173439.3e0d2799.davem@davemloft.net> <20040930181248.48185e41.davem@davemloft.net> <20040930204005.69115c0e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040930204005.69115c0e.davem@davemloft.net> X-archive-position: 9765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > How do things look for you with this change Andi? > If things are still out of whack, play around with > different values of /proc/sys/net/ipv4/tcp_tso_win_divisor Still slower, like previously reported. But I tried tweaking the sysctl now. Result is that 2 is pretty good (only 3MB/s) slower and >20 is also pretty good (2MB/s slower). Everything inbetween is a lot slower, varying a bit. I wasn't able to find a setting that gave the same results as TSO off though, although the difference is not that dramatic anymore. -Andi From mlindner@syskonnect.de Fri Oct 1 04:51:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 04:51:58 -0700 (PDT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91Bpomx011603 for ; Fri, 1 Oct 2004 04:51:51 -0700 Received: from syskonnect.de (skd.de [10.9.15.1]) by gatekeeper.syskonnect.de (8.12.10/8.12.10) with ESMTP id i91Bq1FR023834; Fri, 1 Oct 2004 13:52:01 +0200 (MET DST) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.9-patch8.359.2.8/8.12.9) with ESMTP id i91Bpa7A006792; Fri, 1 Oct 2004 13:51:37 +0200 (MET DST) Message-ID: <415D46BE.3080904@syskonnect.de> Date: Fri, 01 Oct 2004 13:59:58 +0200 From: Mirko Lindner User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Schmidt CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc3] sk98lin - register the driver with hotplug References: <415C8322.7030005@stud.feec.vutbr.cz> In-Reply-To: <415C8322.7030005@stud.feec.vutbr.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mlindner@syskonnect.de Precedence: bulk X-list: netdev Hi Michal, thanks for the patch. I'll include the changes into the driver. Cheers, Mirko Michal Schmidt wrote: > Hello, > > The attached patch allows the sk98lin module to be loaded automatically > by hotplug. > > Michal Schmidt > > > ------------------------------------------------------------------------ > > --- linux-2.6.9-rc3.orig/drivers/net/sk98lin/skge.c 2004-09-30 23:38:44.181252712 +0200 > +++ linux-2.6.9-rc3/drivers/net/sk98lin/skge.c 2004-09-30 21:02:04.000000000 +0200 > @@ -5169,6 +5169,8 @@ static struct pci_device_id skge_pci_tbl > { 0, } > }; > > +MODULE_DEVICE_TABLE(pci, skge_pci_tbl); > + > static struct pci_driver skge_driver = { > .name = "skge", > .id_table = skge_pci_tbl, From hadi@znyx.com Fri Oct 1 05:26:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 05:26:29 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91CQN5I012596 for ; Fri, 1 Oct 2004 05:26:24 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100105282612:10211 ; Fri, 1 Oct 2004 05:28:26 -0700 Subject: e1000 patchlet From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Jeff Garzik , john.ronciak@intel.com, ganesh.venkatesan@intel.com Cc: netdev@oss.sgi.com Organization: ZNYX Networks Message-Id: <1096633537.1041.87.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Oct 2004 08:25:37 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/01/2004 05:28:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/01/2004 05:29:00 AM, Serialize complete at 10/01/2004 05:29:00 AM Content-Type: multipart/mixed; boundary="=-5j0yS34gsvXTv80xkOnb" X-archive-position: 9767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev --=-5j0yS34gsvXTv80xkOnb Content-Transfer-Encoding: 7bit Content-Type: text/plain attached cheers, jamal --=-5j0yS34gsvXTv80xkOnb Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=e1000p1 Content-Type: text/plain; name=e1000p1; charset=ISO-8859-1 --- a/drivers/net/e1000/e1000_main.c 2004/10/01 12:09:51 1.1 +++ b/drivers/net/e1000/e1000_main.c 2004/10/01 12:12:48 @@ -1773,7 +1773,6 @@ unsigned int mss = 0; int count = 0; unsigned int f; - nr_frags = skb_shinfo(skb)->nr_frags; len -= skb->data_len; if(unlikely(skb->len <= 0)) { --=-5j0yS34gsvXTv80xkOnb-- From herbert@gondor.apana.org.au Fri Oct 1 06:06:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 06:06:43 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91D6XGp014609 for ; Fri, 1 Oct 2004 06:06:35 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CDN71-00059X-00; Fri, 01 Oct 2004 23:06:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CDN6w-0001p1-00; Fri, 01 Oct 2004 23:06:10 +1000 Date: Fri, 1 Oct 2004 23:06:09 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com, ak@suse.de, jheffner@psc.edu Subject: Re: Current 2.6.x TSO state Message-ID: <20041001130609.GA6979@gondor.apana.org.au> References: <20040930213221.06a3f5b3.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040930213221.06a3f5b3.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Sep 30, 2004 at 09:32:21PM -0700, David S. Miller wrote: > > diff4) Obey MSS in tso handling, shrink tcp_skb_cb This looks great. But can we please rename tcp_skb_psize to tcp_skb_mss? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From vkondra@mail.ru Fri Oct 1 07:32:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 07:32:30 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91EWMtE016447 for ; Fri, 1 Oct 2004 07:32:23 -0700 Received: from [82.80.3.97] (port=10097 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1CDORx-000Bpr-00; Fri, 01 Oct 2004 18:32:01 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: generic 802.11 stack Date: Fri, 1 Oct 2004 16:30:42 +0200 User-Agent: KMail/1.7 Cc: "Luis R. Rodriguez" , "David S. Miller" , acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409290910.13201.vkondra@mail.ru> <20040929080011.GO30131@ruslug.rutgers.edu> In-Reply-To: <20040929080011.GO30131@ruslug.rutgers.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart16626391.WQu7vuWcJy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410011630.59465.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 9769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev --nextPart16626391.WQu7vuWcJy Content-Type: multipart/mixed; boundary="Boundary-01=_ToWXBwX6OFYnK9d" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_ToWXBwX6OFYnK9d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Attached is 1-st iteration for generic 802.11 stack framework. Based on code from Dave. I make it compile for 2.6 and wrote simple skeleton for native 802.11 drive= r.=20 This skeleton is able to simulate Rx using ioctl; perl script to invoke ioc= tl=20 included. Argument for script is binary frame image. I removed all code for 802.11 header removal from p80211_type_trans for=20 several reasons: =2D I'd like to have all frames coming to stack with the same 802.11 header= ,=20 this will help for sniffer =2D header removal for data is a bit more complex: we should determine QoS= =20 header and strip 24 or 26 bytes. =2D I'd like to do fragmentation and reassembly on stack, not in driver. Nothing functional yet, but one can start debugging stack using Rx imitatio= n;=20 and driver do print packets it gets to Tx. P.S. question: I saw in all xxx_type_trans functions, skb->dev never assigned, it is done = by=20 driver instead. What is the reason? Why not assign skb->dev in=20 xxx_type_trans? --Boundary-01=_ToWXBwX6OFYnK9d Content-Type: application/x-tbz; name="p80211.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p80211.tar.bz2" QlpoOTFBWSZTWYXE8hIAUOr/9f38TIB//////////v////8gQAQAFAAAAQAQAghgM5599ut87u9b zrld9y6N7l4PvdlU+qe97vVVHdzjM969bdECXdPcere4hdc70a69TnvOknXe7ZnszoKPiAAAAN9f b3e+tcNmi6+++vvtZ9PV2uws3TNj47NOu7dKUGh9b4x6+VKt93EHt7lV7heN673e9z3tbPnmJV9j VPsDT66HZoEoRGgIwE0Jo1MJkwpmI0TNE2mjSaaNTEAAeppo0ABtQYiAEJqYqeyCnponpTaR5T1N 6p5Q9CeoPUPUDQMgMgANAABIRESY0VT8CNKm9U3qemmqflT9TZTTSNNtU9Rp6gN6p5MkAAxAGgAY Sn6pSEmVP0piB6m0mj1NAeo9QAepoaA0aAAAAAAAAESSCmjJqMAmJiPQE0jTTUxHqeU9EM1PUwQZ MyjIPUAeoA0ESRAIBAJpiE0yCYQmnkpoPUHqaeoHknqB5Q09QGmh6jTQPQA6f0fnkPnlQu7ehTo+ zSCGUGUSMBmmAKbmCUg6wVO5znR1S0k6suT6I2G0CRAzAxcTL6i1bY0Vapc0tfXLDvuCGobwGKBI Nd2YWVqyZZTVlxklWKZMyREkRaUdVXH1pVB6aWm4KYR9MDGOo3tX5/JP2N6Dq+aI9axr7IeyKKf1 qsbzsimjJVi+p0s/0dt/0V2Tya47MUJJFGQkCbdCjREqqRjEJRm7ZtMMSpJfZfOXhcvLWjIyGNDb OtrgzpZTCbcevOJ0/fu6YW6a0xdJsjRKn0dzcfh8NG73VR3+LfPwaPC1aV86zVX9Wl2wmqOWN49f 45uTbYzGzkJUMXOIjOj3VCk70AA0yDo+Xk9GLhIoRQ0UJStUU8kqEA9NFRkGYjKKwLLDm1kkGWEt 3mSxBWEV1pEaISHO9rYQShGRAACSxlen23FJ+xWc+K3DMoxEQM+cotJAH4Yeqp7FiV+L1MSBDU8o SHyeTw+46sH+3H6DaxVTQHBigzEFNqjWW45HIcNNRAnpkxiENDGKkuhQdUnNfvhR+D/D2/40Ghv0 DobFhtKi0UFgUIQEhAHSrXDAyiPzym6JE/biVEXHBux03tZVJjer0t5bbFyFLVljb8tuoTOVuSWk wbbLdqJMscue3JxlZxvI4aQq0LRGU/ezVNPLIsMpWMtjpRDqRxsZbuZuZtMw0vO3k5Skqi5AEvmS +gPDEuihaDUZBqK1FCo5Yes7JJQ4fF5eEd0xW2hjp3GwEMvfqEBoGL2iZQaPjgb6CGCQh8EIacPm O/7nT/n/Du7uvXerEkMYOmEbHtI2XImNptOmsOhnAeD8thXhI4Kd7OEkUgkHRKDJgkk+1jyRs8k9 mBC5ur5TV03+vbdnX2JkuJeDlsIXLbbeW3CzixRFKAwyTojYh1gTQ+L0cw7gy57+IwvsItMwzYQg eeXNSksueQHueFr3AjbiHTrJCV/MHPX0H5aB9ny7k639+hhED4EAzuxeTFkSmYkD1418r3HP9TFF SgacqRfGvjebu86TTeRmvoKRzL8lGU/JdEa8/pbgQGFIyCyDh7ZZXvIkIEJiQcxw7rGIex7KuLjw 7nHFal32XCyMoosjKMuJDo3EuEZTSyMtZqiyEqNRoJBqSCSLxjREwUUuCBpBTlvygZbm1i1h4QTd BkRgKJ7s8PkrvTku0dWpn5Oc5YORRTEGKKakFFPH00KXe52NLbsEUCMFIQTmo4+be5vV1djV97e0 78uHfusBbnoQv9byWyQR0HqpQ8RfDK7wdZ5IWm6d3Dot2iHDDwHahqZlNwJlwrE6xt+M4/f88qJe yDIkhK6faDZ8pHkE5W5fN9uQDh+7SvJqNCFJebIHXU38heQ9Xd9Fz0PuGV8r+dnEGdSPfiJziwmh jf8+6UWw0Ap0Q+HLddPkBD7YSSSDy3H44P5jm5xOUFONpkFURBwiJinj4SkeDCd/cf+35LB/HCz9 mq9ExtkvbwTx3X7u5Nk8i2xERAgd1XPZmlLHvezNI+Jf75M0m0F+xSg0X6j0+/A85eGtDqvpA1sS Yf3HZvmqG7IVdZ7rtdLkO3nxStruBkITe+94gClui2qsaww7Fz9inJ5juZldNN/3qdRgYXOUMViV AiEPHnSH1RZDgklOWb35pL+1W9B/OQ0OndLZVlftOVfA9RXDbmzL4lojzZevv0AIbnQICdpnAprV DIqY41QomVjbRZxGJAnOXMX7dcz4kBmEBX4rNW5sLPCAmWm0bVJIisAogTUB7YSQflofICWrTA4a CObCkom8wpgdh1jjs9Po9r1/uxrZm9mzuJfOFrQZpyd7TtGdmalncSsLWgzT5PWOqp3BjtRXkDy9 7bcmzRDTDk/rvEgj4kNqRJwiKDhBLIT1qTQbhYT1StKOOkhdPOHKKkqgwoDL3gFXvZHC/LFTLBbw RlxakKhIMyZN348+aE5rvBdk7HT5/ivDPaiG3EQmchxv2Wd8tY8hg7eUpot30Q9OdW9g46XbwyZI PK3bAcCEIkIwlRoUV4hWbTP1KozSt88B85SKUA+XLVXq6REmuWyfal2Yr4oedbrC6prcQQ2Q2tf1 rZS57BOb2HyY2D3C2+qOaAbzxe5tyiWB5RqZzS4rVlftPMkZSiUx1nbGBhmCQYm4BNJJE9nHD8WK mxF9w7yPRt65zGM3YSRYdwYnWG3j9q0joG1DWI+nRmDJupMkROQzPjSo1rmSYMN4pZbOtrRsNVxE aIcY06YeLICdJU1mNyDjPwdgzeaVts2VLK3ztAuLmKaqgeUxIB6mQidvwB2WfBR+efsEVFBhsodY yDATVXDGKBIKCDQegs/ZlaE8QhcR1fF7w9Gc56SfsyaJPHa3VCLkd7XRl57k8dfGOLgQprSfF8Y3 benFOAHEceIFL3uCR3tgGzWzyZqpy9d/2Oq+HDO8jfKxI5zvK4PG4YlJI3HG4SBuZUFCKhBfXBQp UILULkDPMxtlNlwydF9D5bnPrSYk4tNtL0aF9q0GOyZYSUKq03KNQ+EHx5dxxGS6Ah4+qeiOKFsR Sg98WVBoZeOO+EbnFe/U0JRkSnJIAw5T8QnYMKwcCGtt+7m0Gca9NSZJBAEpXQJPvXbWz7dnd5Jj uWpprffr04d9onOPSL4E4AaO1lMRskL5Pzvie+udxSPQzHhAkEsPDyV0iPRos25bWrltb7Kzwh4G cZCEM3vjvw8pqXOWmqi9pFBL3pLwYQxbQ8pKN3kGUGQ6oX7oBSYRdJ5o89sEApWUq53TcPOp8ZNg JHeofYGJoVNwUq9oHOCK78uc7peyE5Zg5C+PnNl555z7AWlBQVFB4oJIa3lGMD/lNICFMRJBWyX8 ldmT8Lv3Y3BStg5I1CNtnvciG1mD8sIfOevT9INJSEAvWRSEGSanNosbm7m3qKc3ewAnm8w9IZxD SlOhrd8Qj3Z96OYn6VZWDu8kIQa41BpUbfsth+iQv6aLvcGPtk88XnAsCfmnbO6Z0YH126DZ8Z0E 5xDOzn3XBiyODF7+T7Rd4O9mtI27r67+RrcgwM1YDo4OZUlkwMPUbVxgYkkk9E4c+JIiLwiLNTpR ccR7qlKwRK1oK1ntLF5rO7LCGBPVluppiDpNp3Go4TvK/NQimzhs8dNO5jfmo0op/Ng9t70sk3Cg XJOlozxiytOaniD1w9LJMKa15N+/O+Ka2nW9NMlKtVPSD30elkmzwM7ZWxSVLxjOU8rqk5qeUHrk 9BZlTJaCqeRb8siqLIzP3FRjHK5NzTm4M2E43yLSL7bmi2VY6vkMq9NmaXZ2mSbk+Kl05ayNUMII zICMTtO6KaC2Gl8b5YamiUkUrdrs9y+6mbva/Whu8tcQcu+Z3bFiTHDvaHIEOqFm32abl0Xw1ark cVmjTKp6KSjPol48rUcjcbpS+nMaszHb2C7NR8padR16NGiVOWYqWfr2ZIou/s1ZYrdpUTfzyx7H k0Ofoi92wTBbA+JvBRRvkdnIsZfkJda1xU0PK4ViCOomzbEK/VHmpla1aYWfX7Gq6p6nb1d9xy22 ZQg2zSLaLhfweyklpUUgKcGklSzbuqF6Ki3LE5Vl5A+igNs5+CEQty7d8vq7eWgXfLWxTYfkcIhg IhtY5mohLfxUwcVYuuXiu7tnRYehfjQk+oi2YMJTSUkZFjALUlNo1UCIVMjO4yRKmlPzyq+zIDGB 3A4x9fZF4252LApdLLFF6pICHwRfr+ujxEA8cQdaDrPwNXQEkJAkQkRyjQ0lERF7JBgErn3j+/9m Kdjfrh5br3PZ3imMJB9sJAQ86iqImspNZ4x4pGcY4UjOkeOJDbHExMSDDDjdSFH0iQHCgw+J0kne 7+7Yg7cOJxXLYpFvc0joEapXd4SXB+c5X8cOnC2mOtpy7JEoUfdgmclurzSBLNgY7XlnNnrw0zCg JeJxykIUpJ69LAJer1AEpgCegLIV2vZ0qCJAERVhCiKmcenNJLZdVpLOb6l8maYNiV/XevWxyl3B vqIbt3RugwaPecUSdgrVgEHXYB75REdQ/JhTI6/FIlB6UXS0IQtFylhAlk4YZSY9c0qIsjRtIlaj IqKgJJ3ZDHabk86KCqIiOcxtY1AJ/izcI9zCt0+4/zrR9cFFduXw4XOffFre0PSviJxhu4sUq9SD OSoVElHDj19Pc/PxIiSJ4bijIAnh4TSdp+YgobHKMhz6zeEgeBkRhKIpJVZhW42GuWq7dgzEe+oG 7AWGMrbE8nwlWtd47156mjvgg+HJ61kteLnv1EI9TQC5GFg7SJjgo2oODIoNpNEAH9JEDg/uw/Vs v469u/y9PL4p1A8JvZ0htHBhGjw4xSLPA4I92NEjbE59wYBA3H9i4Cvi5m4me5DWoU9UXOdzsWbJ HP63/rqu35vKKtilfhxlKtrw5OTSGWpgfa3Hg4/L7Uu30CJLfsgSSDPjTW9y3ZWxjbOoiIEUI4pN Qnn8fq9zeZm325AE7PeyAf8wYuonlA58EoqAdJUEJAIQkSMrmDisgdcwwepWgopQRMCAKB/ObsYB pMxpDc7Y091worFUHW8sK1Ir9XhCyRkCib0QsJhEPoaDIU2Ljf40QoYhJtMaCwkgmwGxHwf2wFUg KJhYmIT25uG7Bw6LtXROdwqEQv35wo4um29YAshfUC26V9mz3qfGfeSVRr2xRijBZ5SwAIxFUijE YiIEYuuUBm1crXsaVANnuf8QUNAL2gJglV6G79fs0NekD4w7nOaTO4JC4FeAgIGizLkhdYkIkcXR OQQmyoS4SJhIEIjN9LF99mano9mBthWgtjelxYcjiGA2QIJAFcmac30tdxwROw3mU4GeYq64CNpZ TdNvTUBjDkHKtBAabSt5pNui634MV7asmtgXp0PDU1sMZqidNkN4ztRhgFDPGBa11UfBlKMBKQDI ZISFMPIBQjKnmQlLIGtU8QjaFN0O1EghlAW7Ddu2DOhNQG+Bfyz9BLm8Y66a5ml9/CsBuYE3F6uQ 1EdR7RdMaBOcDnYMLib0DcdsgxH7XlaVFCw8NyKrACgxRJDBQW5wm74Th8jMUH4Rw9F8Dnq9B/nl ncd368vlki9bSg7venCD/I4TgkLDtbvaLBlZgYFGCLnWq/1uBNSNvP7Dn0tQpxPXi4cI88rfS9QR AkhND9q95eR2gvuBun2RG2RwI8woMOHi5FBEeomquMiqbXO7EkMtYXDM5kPoWN9rHvmCICIfNIYT 59iOIz7dN1sU0zSmMriBkENm6nFQU5siA8VjE2hCGdPJ7sKcsxNDYjELHLN9QskYLhVe7Tl4T4cg 26Xz9122tyxgESkketmKQTWuZyNW0bjbWLBWDKQmfoU9KkYmxYxOsxW3Q/BnS8DEJVYLVMtG0shh sRoMzUY8A4+L69iShTOR7oqaL2DWAc9P7t7iprOnUVJ6p895JKoAtBsAfPC9UiR+DIyyGWV18e24 eozVLbqepWbK46N2Qmon4v1fSNIckAT22KD+oih+GV98KQJCECfD/C3xfLDRhkYBRIivyCis1mGs MVMEm9x4HHFBJDEiYRTzw/Hl5dpNa45g117b/qPU+vur9P6Nce3w5dGS+12tsut7PPXzAJn3xNWA jDLFV8iAjvn9Hg7zna4o9i9j7fi9VOH0SOkjzphnXyHr/guLWEjjj9aYFBfyqfhgN8FqJ+xE+RGU JNYJy+8d3C7h28Aua31DplCWkkISTU5CO7epzAxYM5kyhJIGgOuAGJA4bmT85AMv1h1tJtJzAAat wW/WB4St77TsiQjjzfMwlBZfCNMa7djzqnnDb/ZRhU3uCdPNzVmx68dLQNgqTIxcOngAaiYAzswF LSPBK2mRj1R2iZkiChgFmWYhUG4ueAOaGWxp0pf+8LlwtbizDsDF1N16UqMjIft1/h8qqUR9367X z4ZgdUPPriG8WBCjfkjJIEIygoDDDrt4ZvFDfgVCvYfv74nAPLxOOIWhbwMBVX3PsDjtMc6H0XTH W/VqIAHMQANS8DxNLKpT0DZHzHEV7ThcAtt1HnhqAQ248QTJT3J2CYGQmwqW4myP+UAh7kkbY6tK Oc/aOJ7iq7QwDWhJDYgIwjTGwRbEUDuWBdAALhiQKKNw9XC7TY2z47rgDeNlUKHDAtyukYh+5s4+ tK5QJQFIsAXkFU7pK31gJ6F7DVj3UPmHsKHv7EyYmsHM6zjNkgSxAtbyAAtvsadVrwW4CZWTm8I3 5HWZtbdOKeRnVvfiKYYmYKMZ5kX2rjjiJZZqtkiImIiIiIt4uOIiIiJImUikIAtiIl08wAI6b4FA etg9oR47s2w4iTkeJ6CpHCPIPBwzHfic4HWFyBlAPdYpJ59PVfgWhAfGSzvCK68tkJnGgeZtuG3Q mHbWUEjOxNcbJ4lYIsFShsHEux3erZQxALPtlJhxmWnHB4CO0AbMRC567Tt+mis+emQbnYevKoQH +MeS9AgWCQQ/149w2N7mHmGgX1/dENTyIm8GNJCuCQdE1PmyUdMrjklkyCQR6vlCm+S5gTH6IVmj pkAaq2tc8549/q9bXf46geRIbRLSUhQPyCGeQwgSgNdR6lDRcAx8dCEWeyv5DFR53Om401E6sXG4 jbGtZ7pCHHKHp3TfZCnf2mHG+zG4jwnR46dk8QJFVS/7N2ouHkf6exvtrjD1kjJKqpK5ic8fogG8 g9D2e2wmkhh752gHPzasYgkkogEuppxJi/DQMzhGQPI4+v1a+HpjkNy24VLBqRY+NCZ8dS+fTNxD EE9MQNF81HAxxANXQSHVEXecVLDnYj3eOevqKkkwP1YZBSVbgbrYl0dUnbs3DzEe4OTq8sCJ6HKr RQDMDrobhuun0JVA8cmEHhbnhs9gaxgd2wBY0FTsttPbkLuYCIcg799hMhHTs8QthytBUvyHv8HP ssYy9++9iEOo5h3XoTIKFoHgQE6l4w1ATP7f3cP24Z6Q6p3kSlsIxFdSt3D5rFiGPoW06uzUkmXO HA6s4QkEC0ZTQRhGCFLS0jUAjEJVQgIwaQgC52DuaRchMU9SPgBsibzt01TZN0LeHBTHJTY+E1HO LxpOPq8BHHLtMbH4ICecGoMgHJfbXunA7TuT/ZCrQ6zkpuIYLkuJioxZJ6dXf3CaqgMEcwuyOT2f D774ujiD4yAHiIIvfwX5PnDr9wfiB/1cwEogJMOpoHJUdCKdBvQ89u/1YREF6fLsCDr0bBVFFG0b J5zwvoPpfOfMfEcBneFxw33OZzOaDQaDQ1GhsNBoNBodDOWhy2JEbDselBDq5eTsB8CAWyN28t5K cSP5mGCkBEA8CVic4h+7k4e7tqKDxZZizOiznjL5fl9nby97BALEkGcK96D7qkAdjWcbGqwdtRlM l6m+qFrA0g47cLmzN4XMk/Dgn0n3atsdnLViXHo7ijettOIprxTm8bHoDEGDTpIDtStjbIlfDFfy 2aetSBqpF5pIQcCbVUJJJCQkwpzBlUaxSXMPIQFfAMMqkHJeGCqBkJdoRslHHIetgtgyhgsPEo6d E6fA2LC+lu5el769rH1ty+Fm3F7nlbCQkeZbbCR+HMyrnbl4fqzLya6e8OY3dtTdN3bbYSGmjd26 Z3kM669K6q+vipndOu64/Fltt27u22wkJHXLZsWJNX5CZTBxSkTAwJPqM5n1M0mJskO5iczB/Xlv JHI23l26N3SGWJsjMKqpAiQuHFd9k46AIH8QSbyHXpNNiZxgHMwIQgkkkkmMSYxJJJJjIxkkkkJc 63mGQHBwuA79MyHVQVLEJJTjDfrCQIHEYllrAscdxiBobGpJjpJAjJAjGEkkhN7inCj+QeTljzwb m95h2d3O264SEjtlKkxKC8fpmaTOaI0MxZoPec7NRtjG6ASUq2NjeEl03YiJK7mXK6R1d15LOLrs yzMnQo5ZAMBUgnkLnvPtc0ApjbrZZyZmgat2j4QCYEqRBZODxQrakLwuCCYWquaIlIlSc9AJsFkP qiOaLtgOweS2ARPGEELogQodpPGtdaJpdlNAEprVbU0XSDMwzMMzCigxi9OVUbg+hqOcDvhhGStC 536yQkO0q9pUqWsN/X8v6yWgVVJUFSmgoKqF6OqDcAj6h0SuWSNS1AtCQLUw5rU0PoQT5ZMXzbqz IiCDqSMvT0yupdlL5cmI/K+Qb0xiYlOxnOeB9dQJOhBh6vhkY8e3TQ1T+XAbAY7G7Mcv12UbE0DM HVNnOlJLPrtIde+v8MyTED+E2N8MNZsiexQzMLPK8oBMAJdL7fV6nrzPBmeNiZRmYnB7Jrb1y04h Ro3ksBYUSG4eyxYCHZ4SFHHE180bVaSSSEP5rFuPTlxSJueacw6p+A3ogIcrsU8oQHVNc2D6bemL 7F0rTGLzg7Q7V0RPPpiF3i0dh8xxB/d8tDxOJgXvxHPnlT6Ufspt+6jXFA2ZcO+hryxG2yRCyQ1R 4uD4I4JdrAERy2m2233HdRRC2vFqDyWxX4g3Xc5AGQJuAmv8G8oLh+E7lD15OcQN26gG0bwtagC8 qDBvQwHUxhNZr5U3ZC3mYVtSzhbFZtM2okzCs6eL1XcWrU9QI9R8bz1d9SGh8h8E3LmBhmYj+c3h Y1NwU2i5MOv8WMmJdUvuR7ur2IAh1nThRqGonIdgWpFqMS/MGw9ejSe04YncQUXem4KD1z9N7yEe ZjazyiYwJeOQQhahitZsVEs1RuOrp33HVc4JF4oGu6J6pmaVuh20CDIwLYPFSFPBS50GtYCViiB4 xa6reMBK5qxi1tAjQRHaIbh951llMgiFzrvIYEpeUeaVCLISooHO3JwXHrkNF1b8SpLVnQE3IbW4 DGAJEuRE2GjM8Wi3Tn2eqhpmGE6k5e0q//IkFFwojwATLe90PcmBi12ncSrESN7VNrsUgNtDVBhx G9Q+mU+P8dFOmsaaFA3iBiG5AZBhhHNHXYbIXHkeJ3qLrysUZb3ch3BxkAkJJAYIEUSMYwMRGJYG 1spoHueFK+iZFzWg3YcNPs893ybzhQV/0/gzrHD3X9+h26gesgQyvjjudblI6mbbD47YGACYLAhs RqOO/aSAqYmBMb3IyMjJEAqx7r9/SVKxAHanH13xTPZUNlWuIZVziIWs2iVLQneIhDFRE18MYQGQ yyiKiArbZt7EIZ4mbjkwyRTBbElCDYAiz4k4zUYSVlbjN9CJELhZgQcyAJXy6NtNsNtmSTDey2fe KwsVAsG8msLLbTpNjYQ0t2vYDgi6X1De15GI2HmxBILv/fMyAWR6+I2iH57tdA3WhoQsW6EFF5nk Ycu2AkK82AH2qdGI209ybVvKjMumDHCmZXzOCMI2QIAGm9Ax0AbpVCK18NKMVziYGQXVFNwHI/KT 2vq+eHJO5XzQ0pdjgDp0ClZEWQN7ddWSEFFg9DmiGGBfkWMdZoGgHU/GM8wDu4dmrqJIkgpIRZu3 YGhi5MXa+l+F1VnKWzcEUDXQooeGssQmEXIcJ5ehMSOJOfLqPX4BIjyBuzS2mq2aABtRO7Dl7pbK gkjHHNMb3g9YIWkZFBT5ArdKdTDixwjDggTaO+Ro8xmsQCxfY3mVIUg3bUXpJSCfecOHh8VnRPoy 001HZUPjAVwOQhy+WCCSIT1lCvE605D9eZjOR5lvvg6LTlQ39GqBniqUoBF5A6o1CD+OrAGBg+dC dG0fu/T/kLGGcfrHZc/rrw94D1OYh2AUGGPpiDmuoqE1xMg7g1/s29UINhFaGiO56HFcQBC7uRDA x61+lmB0gw0BnhMg9Gg3ERbZG8YUuZ0p06xrA3nVBJE5RKSWCjxVvmc4hDI1OJbNTAMT5VLIZj/w /7fW+Bw0NSSSiZ8nsQnk/GgatZoD5YHzVCJgAkQuYVz951+OnZbJMQK/qVpbE+ZK3GuiSSZCBE5z XOEFiUiZMCH3Slxi3NS+IE8qH23AF+qAu2BpAQRwWbzOG7akCwGXUHIzI1Qfn4pzNWSQx/EB/1sT l7hP2+PAOFO2ookfd88CwfEVxqJxTi3SksSQXlRIUtMShUKS4RHmGfq5gFBob8BO7+L1FUwZ76bR kJEsRS7+VNB18Umt9caH7cv5/2ef+6/T36+HUH0pvOQwQPZjZ3A2gJUkVwbatAPMg00gmBMZUKCp NYH3fXvE0y7wR3Iq6ntjTdFdCICR/kePPkDWSbRR9sTgZ6xxe6JPSAzIjQoOi4KPUsXo7m+dvgt3 26587c5kwAAAAAAAAAAAAAAAAAHO9lxyknT2noy3AQ5ihRsIJH5SkOxB6vxlHQ6/sVFMQPD01PBJ JCEu4jbcifQa66fJ+TxM2qrCSkktJKINoNDvE19MIHQdSA8xSzqBaSa8vYwWIhxsiEmCoFIEUBO/ eWM8IeSWEPAV6sdb48fgfgAZcHD2Ce8BmfcPmA0sRQcGTZsuEkH54OHPIsqVGxoRCAlGxtIvRDRM FoyyDRNLFgtcObnn+bf3h2m6fN0TeaWd5Cqg8Kot2yqJSzrAWhQdIiahgJg9PzReJ+BkwQwvfi8r cKC1rt/bbBwTCGNV/NjjgYfk23J6cTmqKd7ALj1Hpf1pZETV9E114ihyw9OmwdYF012mvCpONgiA xEiXQYQUKkF1VYPRpzQa/1tAcwkbvemGWdUugBcEfl8jeDjpOuvLP3QcTaLLhXNDiG2U2UQUKIIn BEFR1nWHVzomPG8R3LkNF+ymVXZUzqQiOYxOAzA9EWCJUu+shCYFDSp0KSToUlyWawPK6KMvSScW tGZvHcn1BVcfnOj1kKdtySWwX6A8wi8MLmu0g117rjOoQJgdbqtPRASzcsIQ4MCirKRTIyR1RQ8t H3RKztxMBCNuII0dbQUMQ/ker1mTCCmBaViqCIG7CCr4XORx7KtuRdMZBgIzTW0AqCFJBAaISDMR uWRs6iNVgqLaASo5BDmhfa/KPXZdflLZGCJAn1cEr9B0D6YWPtWoYH03sTRLUf7Scg5KCEiJ0J8O dKmMTrCOJ157g+EDufOiirh7677POtRdjU2QjJCkK2uFjyEzFjFhRWZmFXDNewpu0F2FhiIDqsSs AwcRC4tcGIoDVagJxQES3lh1+PmDoOyotQVDYut3SvyQOYlxEtKnh6rXuVE900G2lf5xuasAe1hu 2kB8fj5GWDuGQBiYtNKMP46zXrB58w+lJJFkCKe3YLVEfBq8ABpesiHrmtRM/HBJCBJV0/VBXt6A 4riBCjNLPJMdq6rjzbCG2A/NMMAwHYsZBMS5BoLp15t9PG9uMJyadVNA/UnTqXGJrN59oUdJ4ph9 xzTsuX0+tdl8PahwQQwNHRjMql5yMmu2vIm/xHFlTTBWVFVSSMMaCJlpeXWGY0NjOYJhoevXhuV0 kKDba1eajJwY4yhTg9wuiasyYgkp84cYvhWKwy5CcxJjAhAYWy8IgRlkoTKdFMlL1sppmSFMjGyU F0MBmOKFswXHXqZ0fk/1/39/wz/D7/h8PhRcoqiJmRai5kDZ4waNnuQiHsmAr1IiIiIiIiIiIiMy yIiIiOS1EREREREREREZlkREY2NjcZbH8cJ8cI77H3D/OuHeS/N4s7uR0GiakkJDx/gabJxu4oPG 4FOoPb6cTa5ME7xdtUvnvQorC16MIp/AcZRyB/D6x9EJGQccHGMCjFeVTRHdemX2J7uFvwM5718W ULpmBFRlQXOhZD1kCGA+cFfyCMT8ftKCpJKZA21oLSWsXo6SHp4Q46qhgocEEmBYtWmLMLOUseNl wzWHF63eFDNu21YUljuM5dPG0RNrOlUm2zDA+1A0JD23k7TuxvSaG1MAlHoWWgGQCbbqsee5okWR RLGRaxOGedWTTDLCDwMqLxbsoBz3P5zFWy952QsQVoEoFqS5dVRp2Gd6rJaSjDTJIMyLQiFsjKy3 Gu1p4NTp5d9GwP3NujNv0KLkzToTeUDENe7j0ZFRTT0zoHqqh+7t/+/EtC0CQ5ZTuyo4hxhKeFxD iTw3buAUEDROI7MKkQak4ZQISEgCswPiwIYoHb3R/EgxWAmQEsCJ4J1uMRFLmqokYJBlpL1ZdZ56 K5i5Ieqy2cXXxAzV0iXZwC5VjckA7FLAZgghjXYBEMH7sj4aSNCSgjMYVX9v/bx3R9Lz+1WkBoIx qoNCkUPG4DfGiHKXUtwrdw7Nv0ne1ajHz3IEfOi0gxkY2OYjerqKwu6evxYrPREpir3Y11bZjBji ZxB6LqGAhHjBjPN6iiNI5pnfhO8SeHiWxNSSSBmPv3J9Wblbl3Jr3EikgEKOIXkuIXdpe2XwHlqA rrd5WqP2GNg0DE1tj+JY1EwGsyKYCmPchYwu77CYyRJBEHVw3IAui56ZBJemS5EECMSUR8zKD0vB rBq7oyy2NlxHlDcuPdF9RAsabIAfs5g4/6L2EJaYgzxHq39QZL2xBE+YSKdzugW1ew2Nu4gdK0AZ nLdzCqWMeCgbQ7zG8HIHgBq6yfEUTJubaMxnp1045cio6Zxtukb3uMtMTOUkSLNy73PjlMwTv/is MQFZn2KyqabEhoScIo9COoIVNpsEpVQy6qMhJcrjYR3w1oyM+k37rEy659Cnj59I8LzI7LpB4tNG ppCymORM91GL/GH0hkVplR+WfJHEkQNct8M8Kg6YpUFMTOKErUYgS4GpY6701hhaSAdVoFOZom80 3ZqgGsAMTSs9COdUGlFGFJTTJTIEl+PTUZRv0Ksolx6YuqNDAzgi8pp3Zis4o2FhkxJi6xeuYOtA mS27GhDINcQotJ0rQ051ZRDK40XsSwagoG/kNu428rgnX8spTdBFJAiGqbIJspvIEIYQOhDX6pcm JyQw+yDLVxw02+koHeoQOOYmloXSw6CiZhtRa1Dbr6cbhIugm6sCXMkCCAaeU+HvoDgkIQeQLS5Z p4iXcK4Gtt6+ArWITDhxL2yB1FpEEP70oAyIZPOY9skkkIWtvOEtD1Y2SNqFB5eHVv8By8Z5iIvZ TNTmWW6LCSYJUPrFB9deZHZ2mzoiwTGEie6WBbFC7EELBgA47kdwIIeII8xD6P0SRXkAj3CQDupO NESf5tImGdBMkg9EA7UgmWskA6GvDBgvwxc5SO1TuYMMmx59XkyJwArjkHXAQfvzd0dmagdjFhbe 2PsBvfNmoWEAhB7B1jdV9o3comK8BQ93pgEWoJnEKgkhUajIglMSAqSAyDIlHg6YGKInKxpL51pe 9kzB54n1QVun8oOwPj+Hyrf5EDvgSEkg2Q+za3My/BubnbAzger8xaxzJv+NCIGAxG0kRbPKgfP2 a+D6xg19WGCTpjhI4JKFejeY7ZfaSBbCtLzv8j0PAG/Jue5/XG/vChiKIXQBxSDCLA3U2NpbIujt hzLptWM3TyWGdVpg8JAnVBIUOEYR/CmSYBTtwDAh3etRcUxL8p2eYU7XYUOWASJBAIQSBIRjAIPi IhUHCAf6GDjBue0JmlKrICY2AnMv3r7xvlMA2qGhbIh/8XckU4UJCFxPISA= --Boundary-01=_ToWXBwX6OFYnK9d-- --nextPart16626391.WQu7vuWcJy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBXWojqxdj7mhC6o0RApj6AKCFkyLZ/ge8sdgGqoGaeowKYhlVKgCghugH 21AIH4NzEcj9q1RRPAdU4Lw= =vK7r -----END PGP SIGNATURE----- --nextPart16626391.WQu7vuWcJy-- From cfriesen@nortelnetworks.com Fri Oct 1 09:36:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 09:36:19 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91GaDkk024975 for ; Fri, 1 Oct 2004 09:36:14 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i91GZsR20546; Fri, 1 Oct 2004 12:35:54 -0400 (EDT) Received: from nortelnetworks.com (acart21w.ca.nortel.com [47.130.25.15]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPKMFM; Fri, 1 Oct 2004 12:35:53 -0400 Message-ID: <415D8768.8080808@nortelnetworks.com> Date: Fri, 01 Oct 2004 10:35:52 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linuxppc-dev@ozlabs.org Subject: kernel crash with G5 Xserve and sungem driver Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev I have patched 2.6.9-rc2 to run in 32-bit mode on the G5 Xserve. When I compile a kernel with the tigon driver and the sungem driver both built-in, the kernel crashes. Removing the sungem driver fixes the problem. Is there a known incompatibility between the sungem driver and the Xserve? I don't have crash output at the moment, but I can probably get it eventually. Chris From greg@kroah.com Fri Oct 1 09:55:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 09:55:57 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91GtpSv025464 for ; Fri, 1 Oct 2004 09:55:52 -0700 Received: from DYN319081BLD.beaverton.ibm.com (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id i91GtZG03896; Fri, 1 Oct 2004 09:55:35 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1CDQgl-33X-00; Fri, 01 Oct 2004 09:55:23 -0700 Date: Fri, 1 Oct 2004 09:55:23 -0700 From: Greg KH To: Margit Schubert-While Cc: Jeff Garzik , netdev@oss.sgi.com, kernel-janitors@lists.osdl.org, mcgrof@studorgs.rutgers.edu, prism54-devel@prism54.org, hvr@gnu.org Subject: Re: [Kernel-janitors] Re: [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20041001165523.GC11646@kroah.com> References: <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> <20040923221303.GB13244@us.ibm.com> <20040923221303.GB13244@us.ibm.com> <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> <5.1.0.14.2.20041001084419.02570b18@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20041001084419.02570b18@pop.t-online.de> User-Agent: Mutt/1.5.6i X-archive-position: 9771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Fri, Oct 01, 2004 at 09:04:27AM +0200, Margit Schubert-While wrote: > At 00:15 01.10.2004 -0400, Jeff scribeth: > >I would rather see an msleep implementation in 2.4.x... > > Hear, hear. > And can we PLEASE have a > "#define HAVE_MSLEEP" in delay.h ?!!! > (2.4. AND 2.6) No, this is not how the kernel source tree works, sorry. greg k-h From laforge@gnumonks.org Fri Oct 1 12:32:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 12:32:14 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91JW807031757 for ; Fri, 1 Oct 2004 12:32:09 -0700 Received: from dsl-213-023-154-116.arcor-ip.net ([213.23.154.116] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CDT8F-0004zt-66; Fri, 01 Oct 2004 21:31:55 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CDT8D-0007W7-CX; Fri, 01 Oct 2004 21:31:53 +0200 Date: Fri, 1 Oct 2004 21:31:53 +0200 From: Harald Welte To: Chris Friesen Cc: netdev@oss.sgi.com, linuxppc-dev@ozlabs.org Subject: Re: kernel crash with G5 Xserve and sungem driver Message-ID: <20041001193153.GN27499@sunbeam.de.gnumonks.org> References: <415D8768.8080808@nortelnetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1y1tiN5hVw5cPBDe" Content-Disposition: inline In-Reply-To: <415D8768.8080808@nortelnetworks.com> User-Agent: Mutt/1.5.6+20040907i X-archive-position: 9772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --1y1tiN5hVw5cPBDe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2004 at 10:35:52AM -0600, Chris Friesen wrote: >=20 > I have patched 2.6.9-rc2 to run in 32-bit mode on the G5 Xserve. >=20 > When I compile a kernel with the tigon driver and the sungem driver both= =20 > built-in, the kernel crashes. Removing the sungem driver fixes the probl= em. Yes, I had that too. The Problem is that the XServe G5 actually has two sungem MAC's in the chipset but doesn't use them (and apparently their interrupt lines are not connected either). Apple just doesn't put them in their OF tree, but on the PCI they are visible. The ethernet chips actually used and connected to the ethernet sockets on the back side are th3. Just don't compile (or load) the sungem driver on those boxes. > Is there a known incompatibility between the sungem driver and the Xserve? yes. --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --1y1tiN5hVw5cPBDe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBXbCpXaXGVTD0i/8RApp7AJwKFtyJL91PowHWs4uTO6DnaNrthwCgtU9t sJl0u37ydJljoTsEsvOrDlU= =+Ev2 -----END PGP SIGNATURE----- --1y1tiN5hVw5cPBDe-- From cfriesen@nortelnetworks.com Fri Oct 1 12:43:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 12:43:17 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91JhCMD032196 for ; Fri, 1 Oct 2004 12:43:12 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i91Jgk410733; Fri, 1 Oct 2004 15:42:46 -0400 (EDT) Received: from nortelnetworks.com (acart21w.ca.nortel.com [47.130.25.15]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPKN0J; Fri, 1 Oct 2004 15:42:46 -0400 Message-ID: <415DB334.4010809@nortelnetworks.com> Date: Fri, 01 Oct 2004 13:42:44 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Welte CC: netdev@oss.sgi.com, linuxppc-dev@ozlabs.org Subject: Re: kernel crash with G5 Xserve and sungem driver References: <415D8768.8080808@nortelnetworks.com> <20041001193153.GN27499@sunbeam.de.gnumonks.org> In-Reply-To: <20041001193153.GN27499@sunbeam.de.gnumonks.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Harald Welte wrote: > Just don't compile (or load) the sungem driver on those boxes. Hmm. That's a pain. We've got G5 desktops too, and it would be nice to be able to run one kernel for both. It'd be better (IMHO) to fix the driver so it doesn't crash. Chris From laforge@gnumonks.org Fri Oct 1 12:46:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 12:46:49 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91Jkhud032520 for ; Fri, 1 Oct 2004 12:46:44 -0700 Received: from dsl-213-023-154-116.arcor-ip.net ([213.23.154.116] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CDTMN-0005OS-0d; Fri, 01 Oct 2004 21:46:31 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CDTMM-0007Wk-32; Fri, 01 Oct 2004 21:46:30 +0200 Date: Fri, 1 Oct 2004 21:46:30 +0200 From: Harald Welte To: Chris Friesen Cc: netdev@oss.sgi.com, linuxppc-dev@ozlabs.org Subject: Re: kernel crash with G5 Xserve and sungem driver Message-ID: <20041001194630.GO27499@sunbeam.de.gnumonks.org> References: <415D8768.8080808@nortelnetworks.com> <20041001193153.GN27499@sunbeam.de.gnumonks.org> <415DB334.4010809@nortelnetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bzq2cJcN05fcPrs+" Content-Disposition: inline In-Reply-To: <415DB334.4010809@nortelnetworks.com> User-Agent: Mutt/1.5.6+20040907i X-archive-position: 9774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --Bzq2cJcN05fcPrs+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2004 at 01:42:44PM -0600, Chris Friesen wrote: > Harald Welte wrote: >=20 > >Just don't compile (or load) the sungem driver on those boxes. >=20 > Hmm. That's a pain. We've got G5 desktops too, and it would be nice to = be=20 > able to run one kernel for both. It'd be better (IMHO) to fix the driver= =20 > so it doesn't crash. I recommend talking to Bejamin Herrenschmidt, IIRC he already had something in mind in order to fix the issue. I mean, you can always hardcode some exemption into the driver, that's two easy lines ;) > Chris --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --Bzq2cJcN05fcPrs+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBXbQWXaXGVTD0i/8RAolKAJ92G/5zs4wo4XSF2WAsqAaD1+GIkwCeICAs cHBju+40g4MUwbRTfk6R/Zs= =qWQ2 -----END PGP SIGNATURE----- --Bzq2cJcN05fcPrs+-- From davem@davemloft.net Fri Oct 1 12:49:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 12:49:18 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91JnCw0000412 for ; Fri, 1 Oct 2004 12:49:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDTNN-0006NR-00; Fri, 01 Oct 2004 12:47:33 -0700 Date: Fri, 1 Oct 2004 12:47:33 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-Id: <20041001124733.1ac4266a.davem@davemloft.net> In-Reply-To: <20041001121123.19511403.ak@suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Oct 2004 12:11:23 +0200 Andi Kleen wrote: > Do you want me to play with the new sysctl too? Yes. > max win adv: 5840 bytes max win adv: 63712 bytes > min win adv: 5840 bytes min win adv: 5792 bytes That stinks that the receiver is only using a 64K window, that's way too small for gigabit. From ak@suse.de Fri Oct 1 12:52:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 12:52:10 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91Jq4U2000753 for ; Fri, 1 Oct 2004 12:52:05 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 2AB5BCB5E52; Fri, 1 Oct 2004 21:51:47 +0200 (CEST) Date: Fri, 1 Oct 2004 21:51:47 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-ID: <20041001195146.GA23046@wotan.suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> <20041001124733.1ac4266a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041001124733.1ac4266a.davem@davemloft.net> X-archive-position: 9776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Fri, Oct 01, 2004 at 12:47:33PM -0700, David S. Miller wrote: > On Fri, 1 Oct 2004 12:11:23 +0200 > Andi Kleen wrote: > > > Do you want me to play with the new sysctl too? > > Yes. Already did, see my other mail (I should not read incoming mail in the wrong order @) > > > max win adv: 5840 bytes max win adv: 63712 bytes > > min win adv: 5840 bytes min win adv: 5792 bytes > > That stinks that the receiver is only using a 64K window, > that's way too small for gigabit. Just using the default, no tuning. I have some patches in the pipeline to do automatic window tuning based on link speed based on dev->features. But they were actually more intended for 10Gbit/s (where all the defaults are completely inadequate) And it needs a bit more work. -Andi From davem@davemloft.net Fri Oct 1 12:58:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 12:58:27 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91JwMQK001187 for ; Fri, 1 Oct 2004 12:58:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDTWF-0006P0-00; Fri, 01 Oct 2004 12:56:43 -0700 Date: Fri, 1 Oct 2004 12:56:43 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-Id: <20041001125643.30c6830f.davem@davemloft.net> In-Reply-To: <20041001195146.GA23046@wotan.suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> <20041001124733.1ac4266a.davem@davemloft.net> <20041001195146.GA23046@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Oct 2004 21:51:47 +0200 Andi Kleen wrote: > > > max win adv: 5840 bytes max win adv: 63712 bytes > > > min win adv: 5840 bytes min win adv: 5792 bytes > > > > That stinks that the receiver is only using a 64K window, > > that's way too small for gigabit. > > Just using the default, no tuning. > > I have some patches in the pipeline to do automatic window tuning > based on link speed based on dev->features. But they were actually more > intended for 10Gbit/s (where all the defaults are completely inadequate) > And it needs a bit more work. As mentioned, the TCP receive buffer auto-tuning takes care of all of this in 2.6.6 and later. It's just 2.6.5 doesn't have John Heffner's auto-tuning code which is why your test case is so stuck in the mud. Also, the stretch ACK's are quite normal. If the receiver can't advertize a larger window, we won't spit out an ACK until the ack timeout. From ak@suse.de Fri Oct 1 13:04:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 13:05:00 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91K4qOO001574 for ; Fri, 1 Oct 2004 13:04:55 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D15E1CB3481; Fri, 1 Oct 2004 22:01:02 +0200 (CEST) Date: Fri, 1 Oct 2004 22:01:02 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-ID: <20041001200102.GB23046@wotan.suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> <20041001124733.1ac4266a.davem@davemloft.net> <20041001195146.GA23046@wotan.suse.de> <20041001125643.30c6830f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041001125643.30c6830f.davem@davemloft.net> X-archive-position: 9778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > As mentioned, the TCP receive buffer auto-tuning takes care > of all of this in 2.6.6 and later. It's just 2.6.5 doesn't > have John Heffner's auto-tuning code which is why your test > case is so stuck in the mud. > > Also, the stretch ACK's are quite normal. If the receiver can't > advertize a larger window, we won't spit out an ACK until > the ack timeout. Ok, but why is the TSO case still slower? -Andi From davem@davemloft.net Fri Oct 1 13:17:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 13:17:20 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91KHEYk002064 for ; Fri, 1 Oct 2004 13:17:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDToV-0006Tx-00; Fri, 01 Oct 2004 13:15:35 -0700 Date: Fri, 1 Oct 2004 13:15:34 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-Id: <20041001131534.7bcb87ee.davem@davemloft.net> In-Reply-To: <20041001200102.GB23046@wotan.suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> <20041001124733.1ac4266a.davem@davemloft.net> <20041001195146.GA23046@wotan.suse.de> <20041001125643.30c6830f.davem@davemloft.net> <20041001200102.GB23046@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Oct 2004 22:01:02 +0200 Andi Kleen wrote: > > As mentioned, the TCP receive buffer auto-tuning takes care > > of all of this in 2.6.6 and later. It's just 2.6.5 doesn't > > have John Heffner's auto-tuning code which is why your test > > case is so stuck in the mud. > > > > Also, the stretch ACK's are quite normal. If the receiver can't > > advertize a larger window, we won't spit out an ACK until > > the ack timeout. > > Ok, but why is the TSO case still slower? It isn't for me. With the auto-tuning code present at the receiver, at least in my case, the TSO case runs more quickly since my sender is PCI bandwidth limited since the tg3 sits on a 32mhz/33bit PCI bus. From jheffner@psc.edu Fri Oct 1 13:34:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 13:34:06 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91KY1Ne002632 for ; Fri, 1 Oct 2004 13:34:01 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i91KXY30002310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Oct 2004 16:33:34 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i91KXXCW025446; Fri, 1 Oct 2004 16:33:33 -0400 (EDT) Date: Fri, 1 Oct 2004 16:33:33 -0400 (EDT) From: John Heffner To: Andi Kleen cc: "David S. Miller" , , Subject: Re: Current 2.6.x TSO state In-Reply-To: <20041001200102.GB23046@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer1.psc.edu X-Virus-Status: Clean X-archive-position: 9780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev On Fri, 1 Oct 2004, Andi Kleen wrote: > > As mentioned, the TCP receive buffer auto-tuning takes care > > of all of this in 2.6.6 and later. It's just 2.6.5 doesn't > > have John Heffner's auto-tuning code which is why your test > > case is so stuck in the mud. > > > > Also, the stretch ACK's are quite normal. If the receiver can't > > advertize a larger window, we won't spit out an ACK until > > the ack timeout. > > Ok, but why is the TSO case still slower? Because with TSO enabled, you get bigger back-to-back bursts during which the receiving app can't run. -John From davem@davemloft.net Fri Oct 1 13:58:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 13:58:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91KwQOR003448 for ; Fri, 1 Oct 2004 13:58:27 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDUSD-0006ZB-00; Fri, 01 Oct 2004 13:56:37 -0700 Date: Fri, 1 Oct 2004 13:56:36 -0700 From: "David S. Miller" To: Duncan Sands Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, laforge@gnumonks.org Subject: Re: Oops at __neigh_for_each_release (2.6.9-rc3) Message-Id: <20041001135636.0c071602.davem@davemloft.net> In-Reply-To: <200410012217.35264.baldrick@free.fr> References: <200410012217.35264.baldrick@free.fr> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Oct 2004 22:17:35 +0200 Duncan Sands wrote: > EIP is at __neigh_for_each_release+0x32/0xb0 Give this patch a try. And please report networking bugs to netdev@oss.sgi.com in the future, thanks. ===== net/atm/clip.c 1.42 vs edited ===== --- 1.42/net/atm/clip.c 2004-09-23 18:02:32 -07:00 +++ edited/net/atm/clip.c 2004-10-01 13:35:40 -07:00 @@ -984,19 +984,7 @@ static int __init atm_clip_init(void) { - /* we should use neigh_table_init() */ - clip_tbl.lock = RW_LOCK_UNLOCKED; - clip_tbl.kmem_cachep = kmem_cache_create(clip_tbl.id, - clip_tbl.entry_size, 0, SLAB_HWCACHE_ALIGN, NULL, NULL); - - if (!clip_tbl.kmem_cachep) - return -ENOMEM; - - /* so neigh_ifdown() doesn't complain */ - clip_tbl.proxy_timer.data = 0; - clip_tbl.proxy_timer.function = NULL; - init_timer(&clip_tbl.proxy_timer); - skb_queue_head_init(&clip_tbl.proxy_queue); + neigh_table_init(&clip_tbl); clip_tbl_hook = &clip_tbl; register_atm_ioctl(&clip_ioctl_ops); @@ -1022,7 +1010,6 @@ deregister_atm_ioctl(&clip_ioctl_ops); - neigh_ifdown(&clip_tbl, NULL); dev = clip_devs; while (dev) { next = PRIV(dev)->next; @@ -1030,9 +1017,11 @@ free_netdev(dev); dev = next; } - if (start_timer == 0) del_timer(&idle_timer); - kmem_cache_destroy(clip_tbl.kmem_cachep); + neigh_table_clear(&clip_tbl); + + if (start_timer == 0) + del_timer(&idle_timer); clip_tbl_hook = NULL; } From davem@davemloft.net Fri Oct 1 15:15:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:15:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91MF5MA004832 for ; Fri, 1 Oct 2004 15:15:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDVeX-00083S-00; Fri, 01 Oct 2004 15:13:25 -0700 Date: Fri, 1 Oct 2004 15:13:25 -0700 From: "David S. Miller" To: Fernando Gont Cc: netdev@oss.sgi.com Subject: Re: TCP's reaction to soft errors Message-Id: <20041001151325.1bf112a5.davem@davemloft.net> In-Reply-To: <4.3.2.7.2.20040915112853.00cf9980@mail.daleclick.com> References: <4.3.2.7.2.20040915112853.00cf9980@mail.daleclick.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 15 Sep 2004 11:44:14 -0300 Fernando Gont wrote: > The draft proposes to change TCP's reaction to soft errors so that > connections that are in the SYN-SENT or SYN-RECEIVED states are aborted > upon receipt of an ICMP error message that indicates a soft error. I have verified that Linux behaves in a way compliant to this proposal. No changes are necessary. From davem@davemloft.net Fri Oct 1 15:19:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:19:20 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91MJEk6005187 for ; Fri, 1 Oct 2004 15:19:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDViX-00084B-00; Fri, 01 Oct 2004 15:17:33 -0700 Date: Fri, 1 Oct 2004 15:17:32 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [NET] NEIGHBOUR: hold refcnt of net_device from proxy neighbor entries. Message-Id: <20041001151732.60899c38.davem@davemloft.net> In-Reply-To: <20040930.170729.51800585.yoshfuji@linux-ipv6.org> References: <20040930.170729.51800585.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i91MJEk6005187 X-archive-position: 9783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 30 Sep 2004 17:07:29 +0900 (JST) YOSHIFUJI Hideaki / 吉藤英明 wrote: > [NET] NEIGHBOUR: hold refcnt of net_device from proxy neighbor entries. > > We did not hold refcnt of net_device from proxy neighbor entries > while we did from neighbor entries. > > Signed-off-by: Hideaki YOSHIFUJI Applied, thanks. From davem@davemloft.net Fri Oct 1 15:21:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:21:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91ML4Hq005516 for ; Fri, 1 Oct 2004 15:21:04 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDVkJ-00084W-00; Fri, 01 Oct 2004 15:19:23 -0700 Date: Fri, 1 Oct 2004 15:19:23 -0700 From: "David S. Miller" To: Yasuyuki Kozakai Cc: netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [PATCH]: fixed typo of reassembly.c Message-Id: <20041001151923.261b42b3.davem@davemloft.net> In-Reply-To: <200409301023.i8UANRGp002783@toshiba.co.jp> References: <200409301023.i8UANRGp002783@toshiba.co.jp> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 30 Sep 2004 19:23:26 +0900 (JST) Yasuyuki Kozakai wrote: > This patch fixes byte ordering. Please apply this. It is textual fix only, do you realize this? Both ntohs() and htons() perform the same transformation on a 16-bit data item. It really does not matter which one you actually use, in practice. I will apply your patch anyways, I just wanted to be clear that this does not actually fix any bug. :-) THanks. From davem@davemloft.net Fri Oct 1 15:54:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:54:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91MsprD006267 for ; Fri, 1 Oct 2004 15:54:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDWH1-0008Dd-00; Fri, 01 Oct 2004 15:53:11 -0700 Date: Fri, 1 Oct 2004 15:53:10 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, mcgrof@studorgs.rutgers.edu, acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org Subject: Re: generic 802.11 stack Message-Id: <20041001155310.515ee09e.davem@davemloft.net> In-Reply-To: <200410011630.59465.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409290910.13201.vkondra@mail.ru> <20040929080011.GO30131@ruslug.rutgers.edu> <200410011630.59465.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Why this change? -extern void hh_data_is_too_small(void); +static void hh_data_is_too_small(void) +{ + printk(KERN_ERR "hh_data_is_too_small\n"); +} We don't define the function because it is meant to cause a compile time error if hh->hh_data is too small to hold the full p80211_data_header structure. Please undo this change. And therefore undo this change too: - if (sizeof(hh->hh_data) < sizeof(*p)) + if (sizeof(hh->hh_data) < sizeof(*p)) { hh_data_is_too_small(); + return -1; + } Next, what's this? - dev->hard_header = p80211_header; + dev->hard_header = p80211_header; dev->rebuild_header = p80211_rebuild_header; Your merely changing the tab character after dev->hard_header into spaces. Please don't do this. This makes a lot of white space noise when making diffs against the original davem-p80211 code thus making it harder to review the changes you actually made. Next: + dev->mtu = 2304; + dev->type = ARPHRD_IEEE80211; Is this really the correct default MTU for wireless devices? @@ -342,7 +343,7 @@ int p80211_recv_cfackpoll(struct sk_buff static struct packet_type p80211_packet_type = { .type = __constant_htons(ETH_P_802_11), .func = p80211_rcv, - .data = (void *) 1, /* understands shared SKBs */ + .af_packet_priv = (void *) 1, /* understands shared SKBs */ }; You can just remove this line entirely for 2.6.x kernels. Otherwise looks fine :-) From shemminger@osdl.org Fri Oct 1 15:57:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:57:55 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91MvnBF006615 for ; Fri, 1 Oct 2004 15:57:49 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i91MvVWL008069 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Oct 2004 15:57:31 -0700 Date: Fri, 1 Oct 2004 15:55:54 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/3) tcp - choose congestion algorithm at initialization Message-Id: <20041001155554.51763dc0@zqx3.pdx.osdl.net> In-Reply-To: <20040927121610.68f942a4.davem@redhat.com> References: <20040927111834.48c7baab@zqx3.pdx.osdl.net> <20040927121610.68f942a4.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.86 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9786 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 Here is the 2.4 version of the change to store congest algorithm per socket. Signed-off-by: Stephen Hemminger diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h 2004-10-01 15:51:48 -07:00 +++ b/include/net/sock.h 2004-10-01 15:51:48 -07:00 @@ -256,6 +256,13 @@ __u32 end_seq; }; +enum tcp_congestion_algo { + TCP_RENO=0, + TCP_VEGAS, + TCP_WESTWOOD, + TCP_BIC, +}; + struct tcp_opt { int tcp_header_len; /* Bytes of tcp header to send */ @@ -428,7 +435,8 @@ unsigned int keepalive_intvl; /* time interval between keep alive probes */ int linger2; - int frto_counter; /* Number of new acks after RTO */ + __u8 adv_cong; /* Using Vegas, Westwood, or BIC */ + __u8 frto_counter; /* Number of new acks after RTO */ __u32 frto_highmark; /* snd_nxt when RTO occurred */ unsigned long last_synq_overflow; @@ -465,7 +473,6 @@ __u32 beg_snd_nxt; /* right edge during last RTT */ __u32 beg_snd_una; /* left edge during last RTT */ __u32 beg_snd_cwnd; /* saves the size of the cwnd */ - __u8 do_vegas; /* do vegas for this connection */ __u8 doing_vegas_now;/* if true, do vegas for this RTT */ __u16 cntRTT; /* # of RTTs measured within last RTT */ __u32 minRTT; /* min of RTTs measured within last RTT (in usec) */ diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-10-01 15:51:48 -07:00 +++ b/include/net/tcp.h 2004-10-01 15:51:48 -07:00 @@ -1110,6 +1110,13 @@ return tp->packets_out - tp->left_out + tp->retrans_out; } +/* + * Which congestion algorithim is in use on the connection. + */ +#define tcp_is_vegas(__tp) ((__tp)->adv_cong == TCP_VEGAS) +#define tcp_is_westwood(__tp) ((__tp)->adv_cong == TCP_WESTWOOD) +#define tcp_is_bic(__tp) ((__tp)->adv_cong == TCP_BIC) + /* Recalculate snd_ssthresh, we want to set it to: * * Reno: @@ -1122,7 +1129,7 @@ */ static inline __u32 tcp_recalc_ssthresh(struct tcp_opt *tp) { - if (sysctl_tcp_bic) { + if (tcp_is_bic(tp)) { if (sysctl_tcp_bic_fast_convergence && tp->snd_cwnd < tp->bictcp.last_max_cwnd) tp->bictcp.last_max_cwnd @@ -1141,11 +1148,6 @@ /* Stop taking Vegas samples for now. */ #define tcp_vegas_disable(__tp) ((__tp)->vegas.doing_vegas_now = 0) - -/* Is this TCP connection using Vegas (regardless of whether it is taking - * Vegas measurements at the current time)? - */ -#define tcp_is_vegas(__tp) ((__tp)->vegas.do_vegas) static inline void tcp_vegas_enable(struct tcp_opt *tp) { @@ -1179,7 +1181,7 @@ /* Should we be taking Vegas samples right now? */ #define tcp_vegas_enabled(__tp) ((__tp)->vegas.doing_vegas_now) -extern void tcp_vegas_init(struct tcp_opt *tp); +extern void tcp_ca_init(struct tcp_opt *tp); static inline void tcp_set_ca_state(struct tcp_opt *tp, u8 ca_state) { @@ -1978,7 +1980,7 @@ static inline void tcp_westwood_update_rtt(struct tcp_opt *tp, __u32 rtt_seq) { - if (sysctl_tcp_westwood) + if (tcp_is_westwood(tp)) tp->westwood.rtt = rtt_seq; } @@ -2015,13 +2017,13 @@ static inline void tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb) { - if (sysctl_tcp_westwood) + if (tcp_is_westwood(&(sk->tp_pinfo.af_tcp))) __tcp_westwood_fast_bw(sk, skb); } static inline void tcp_westwood_slow_bw(struct sock *sk, struct sk_buff *skb) { - if (sysctl_tcp_westwood) + if (tcp_is_westwood(&(sk->tp_pinfo.af_tcp))) __tcp_westwood_slow_bw(sk, skb); } @@ -2035,7 +2037,7 @@ { __u32 ret = 0; - if (sysctl_tcp_westwood) + if (tcp_is_westwood(tp)) ret = (__u32) (max(__tcp_westwood_bw_rttmin(tp), 2U)); return ret; @@ -2046,7 +2048,7 @@ int ret = 0; __u32 ssthresh; - if (sysctl_tcp_westwood) { + if (tcp_is_westwood(tp)) { if (!(ssthresh = tcp_westwood_bw_rttmin(tp))) return ret; @@ -2062,7 +2064,7 @@ int ret = 0; __u32 cwnd; - if (sysctl_tcp_westwood) { + if (tcp_is_westwood(tp)) { if (!(cwnd = tcp_westwood_bw_rttmin(tp))) return ret; @@ -2077,7 +2079,7 @@ { int ret = 0; - if (sysctl_tcp_westwood) { + if (tcp_is_westwood(tp)) { if (tcp_westwood_cwnd(tp)) { tp->snd_ssthresh = tp->snd_cwnd; ret = 1; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-10-01 15:51:48 -07:00 +++ b/net/ipv4/tcp_input.c 2004-10-01 15:51:48 -07:00 @@ -549,17 +549,20 @@ tcp_grow_window(sk, tp, skb); } -/* Set up a new TCP connection, depending on whether it should be - * using Vegas or not. - */ -void tcp_vegas_init(struct tcp_opt *tp) +/* When starting a new connection, pin down the current choice of + * congestion algorithm. + */ +void tcp_ca_init(struct tcp_opt *tp) { - if (sysctl_tcp_vegas_cong_avoid) { - tp->vegas.do_vegas = 1; + if (sysctl_tcp_westwood) + tp->adv_cong = TCP_WESTWOOD; + else if (sysctl_tcp_bic) + tp->adv_cong = TCP_BIC; + else if (sysctl_tcp_vegas_cong_avoid) { + tp->adv_cong = TCP_VEGAS; tp->vegas.baseRTT = 0x7fffffff; tcp_vegas_enable(tp); - } else - tcp_vegas_disable(tp); + } } /* Do RTT sampling needed for Vegas. @@ -2007,7 +2010,7 @@ static inline __u32 bictcp_cwnd(struct tcp_opt *tp) { /* orignal Reno behaviour */ - if (!sysctl_tcp_bic) + if (!tcp_is_bic(tp)) return tp->snd_cwnd; if (tp->bictcp.last_cwnd == tp->snd_cwnd && diff -Nru a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c --- a/net/ipv4/tcp_minisocks.c 2004-10-01 15:51:48 -07:00 +++ b/net/ipv4/tcp_minisocks.c 2004-10-01 15:51:48 -07:00 @@ -788,7 +788,7 @@ newtp->mss_clamp = req->mss; TCP_ECN_openreq_child(newtp, req); - tcp_vegas_init(newtp); + tcp_ca_init(newtp); TCP_INC_STATS_BH(TcpPassiveOpens); } return newsk; diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-10-01 15:51:48 -07:00 +++ b/net/ipv4/tcp_output.c 2004-10-01 15:51:48 -07:00 @@ -1197,7 +1197,7 @@ tp->window_clamp = dst->window; tp->advmss = dst->advmss; tcp_initialize_rcv_mss(sk); - tcp_vegas_init(tp); + tcp_ca_init(tp); tcp_select_initial_window(tcp_full_space(sk), tp->advmss - (tp->ts_recent_stamp ? tp->tcp_header_len - sizeof(struct tcphdr) : 0), @@ -1248,7 +1248,7 @@ TCP_SKB_CB(buff)->end_seq = tp->write_seq; tp->snd_nxt = tp->write_seq; tp->pushed_seq = tp->write_seq; - tcp_vegas_init(tp); + tcp_ca_init(tp); /* Send it off. */ TCP_SKB_CB(buff)->when = tcp_time_stamp; From shemminger@osdl.org Fri Oct 1 15:57:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:57:57 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91MvoYQ006616 for ; Fri, 1 Oct 2004 15:57:50 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i91MvXWL008095 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Oct 2004 15:57:33 -0700 Date: Fri, 1 Oct 2004 15:56:20 -0700 From: Stephen Hemminger To: Davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] (2/3) tcp diag info for 2.4 Message-Id: <20041001155620.2f11f9f0@zqx3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.86 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This adds vegas style bandwidth info to 2.4. Also: makes 2.6 and 2.4 version of tcp_diag.h identical. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/tcp_diag.h b/include/linux/tcp_diag.h --- a/include/linux/tcp_diag.h 2004-10-01 15:52:21 -07:00 +++ b/include/linux/tcp_diag.h 2004-10-01 15:52:21 -07:00 @@ -98,9 +98,10 @@ TCPDIAG_NONE, TCPDIAG_MEMINFO, TCPDIAG_INFO, + TCPDIAG_VEGASINFO, }; -#define TCPDIAG_MAX TCPDIAG_INFO +#define TCPDIAG_MAX TCPDIAG_VEGASINFO /* TCPDIAG_MEM */ @@ -112,5 +113,15 @@ __u32 tcpdiag_fmem; __u32 tcpdiag_tmem; }; + +/* TCPDIAG_VEGASINFO */ + +struct tcpvegas_info { + __u32 tcpv_enabled; + __u32 tcpv_rttcnt; + __u32 tcpv_rtt; + __u32 tcpv_minrtt; +}; + #endif /* _TCP_DIAG_H_ */ diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c 2004-10-01 15:52:21 -07:00 +++ b/net/ipv4/tcp_diag.c 2004-10-01 15:52:21 -07:00 @@ -49,6 +49,7 @@ struct nlmsghdr *nlh; struct tcp_info *info = NULL; struct tcpdiag_meminfo *minfo = NULL; + struct tcpvegas_info *vinfo = NULL; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, TCPDIAG_GETSOCK, sizeof(*r)); @@ -58,6 +59,10 @@ minfo = TCPDIAG_PUT(skb, TCPDIAG_MEMINFO, sizeof(*minfo)); if (ext & (1<<(TCPDIAG_INFO-1))) info = TCPDIAG_PUT(skb, TCPDIAG_INFO, sizeof(*info)); + + if ((tcp_is_westwood(tp) || tcp_is_vegas(tp)) + && (ext & (1<<(TCPDIAG_VEGASINFO-1)))) + vinfo = TCPDIAG_PUT(skb, TCPDIAG_VEGASINFO, sizeof(*vinfo)); } r->tcpdiag_family = sk->family; r->tcpdiag_state = sk->state; @@ -184,6 +189,20 @@ info->tcpi_snd_cwnd = tp->snd_cwnd; info->tcpi_advmss = tp->advmss; info->tcpi_reordering = tp->reordering; + } + + if (vinfo) { + if (tcp_is_vegas(tp)) { + vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; + vinfo->tcpv_rttcnt = tp->vegas.cntRTT; + vinfo->tcpv_rtt = (1000000*tp->vegas.baseRTT)/HZ; + vinfo->tcpv_minrtt = (1000000*tp->vegas.minRTT)/HZ; + } else { + vinfo->tcpv_enabled = 0; + vinfo->tcpv_rttcnt = 0; + vinfo->tcpv_rtt = (1000000*tp->westwood.rtt)/HZ; + vinfo->tcpv_minrtt = (1000000*tp->westwood.rtt_min)/HZ; + } } nlh->nlmsg_len = skb->tail - b; From shemminger@osdl.org Fri Oct 1 15:57:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 15:57:58 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91MvpGC006617 for ; Fri, 1 Oct 2004 15:57:51 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i91MvYWL008115 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Oct 2004 15:57:34 -0700 Date: Fri, 1 Oct 2004 15:57:25 -0700 From: Stephen Hemminger Cc: davem@redhat.com Subject: [PATCH] (3/3) tcp westwood cleanup for 2.4 Message-Id: <20041001155725.3cd22049@zqx3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.86 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9788 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 Backport of the 2.6 code cleanup for Westwood TCP. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-10-01 15:54:14 -07:00 +++ b/net/ipv4/tcp_input.c 2004-10-01 15:54:14 -07:00 @@ -2556,15 +2556,13 @@ * WESTWOOD_RTT_MIN minimum bound since we could be on a LAN! */ -static inline __u32 westwood_update_rttmin(struct sock *sk) +static inline __u32 westwood_update_rttmin(const struct sock *sk) { - struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); + const struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); __u32 rttmin = tp->westwood.rtt_min; - if (tp->westwood.rtt == 0) - return rttmin; - - if (tp->westwood.rtt < tp->westwood.rtt_min || !rttmin) + if (tp->westwood.rtt != 0 && + (tp->westwood.rtt < tp->westwood.rtt_min || !rttmin)) rttmin = tp->westwood.rtt; return rttmin; @@ -2575,9 +2573,9 @@ * Evaluate increases for dk. */ -static __u32 westwood_acked(struct sock *sk) +static __u32 westwood_acked(const struct sock *sk) { - struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); + const struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); return ((tp->snd_una) - (tp->westwood.snd_una)); } @@ -2591,9 +2589,9 @@ * window, 1 if the sample has to be considered in the next window. */ -static int westwood_new_window(struct sock *sk) +static int westwood_new_window(const struct sock *sk) { - struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); + const struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); __u32 left_bound; __u32 rtt; int ret = 0; @@ -2627,14 +2625,13 @@ struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); __u32 delta = now - tp->westwood.rtt_win_sx; - if (!delta) - return; - - if (tp->westwood.rtt) - westwood_filter(sk, delta); - - tp->westwood.bk = 0; - tp->westwood.rtt_win_sx = tcp_time_stamp; + if (delta) { + if (tp->westwood.rtt) + westwood_filter(sk, delta); + + tp->westwood.bk = 0; + tp->westwood.rtt_win_sx = tcp_time_stamp; + } } static void westwood_update_window(struct sock *sk, __u32 now) @@ -2688,7 +2685,7 @@ static inline int westwood_may_change_cumul(struct tcp_opt *tp) { - return ((tp->westwood.cumul_ack) > westwood_mss(tp)); + return (tp->westwood.cumul_ack > westwood_mss(tp)); } static inline void westwood_partial_update(struct tcp_opt *tp) @@ -2709,7 +2706,7 @@ * delayed or partial acks. */ -static __u32 westwood_acked_count(struct sock *sk) +static inline __u32 westwood_acked_count(struct sock *sk) { struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); @@ -2723,7 +2720,7 @@ if (westwood_may_change_cumul(tp)) { /* Partial or delayed ack */ - if ((tp->westwood.accounted) >= (tp->westwood.cumul_ack)) + if (tp->westwood.accounted >= tp->westwood.cumul_ack) westwood_partial_update(tp); else westwood_complete_update(tp); From ak@suse.de Fri Oct 1 16:22:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 16:22:56 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91NMoPU011330 for ; Fri, 1 Oct 2004 16:22:50 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 05957CB5C94; Sat, 2 Oct 2004 01:19:40 +0200 (CEST) Date: Sat, 2 Oct 2004 01:19:39 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-ID: <20041001231939.GC23046@wotan.suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> <20041001124733.1ac4266a.davem@davemloft.net> <20041001195146.GA23046@wotan.suse.de> <20041001125643.30c6830f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041001125643.30c6830f.davem@davemloft.net> X-archive-position: 9789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > As mentioned, the TCP receive buffer auto-tuning takes care > of all of this in 2.6.6 and later. It's just 2.6.5 doesn't How do you explain the 2-4MB/s less with manually increased receive buffers? -Andi From vkondra@mail.ru Fri Oct 1 16:26:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 16:27:02 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91NQtuq011669 for ; Fri, 1 Oct 2004 16:26:56 -0700 Received: from [82.80.3.97] (port=35851 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1CDWnN-0002DW-00; Sat, 02 Oct 2004 03:26:39 +0400 From: Vladimir Kondratiev To: "David S. Miller" Subject: Re: generic 802.11 stack Date: Sat, 2 Oct 2004 01:25:32 +0200 User-Agent: KMail/1.7 Cc: netdev@oss.sgi.com, mcgrof@studorgs.rutgers.edu, acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200410011630.59465.vkondra@mail.ru> <20041001155310.515ee09e.davem@davemloft.net> In-Reply-To: <20041001155310.515ee09e.davem@davemloft.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6206511.VO1UjDSxoh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410020125.40669.vkondra@mail.ru> X-Spam: Probable Spam X-archive-position: 9790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev --nextPart6206511.VO1UjDSxoh Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 02 October 2004 00:53, David S. Miller wrote: DS> DS> Why this change? DS> DS> -extern void hh_data_is_too_small(void); DS> +static void hh_data_is_too_small(void) DS> +{ DS> + printk(KERN_ERR "hh_data_is_too_small\n"); DS> +} My misunderstanding. Sorry. DS> DS> We don't define the function because it is meant to DS> cause a compile time error if hh->hh_data is too small to DS> hold the full p80211_data_header structure. Please undo DS> this change. DS> DS> And therefore undo this change too: DS> DS> - if (sizeof(hh->hh_data) < sizeof(*p)) DS> + if (sizeof(hh->hh_data) < sizeof(*p)) { DS> hh_data_is_too_small(); DS> + return -1; DS> + } As above. DS> DS> Next, what's this? DS> DS> - dev->hard_header =3D p80211_header; DS> + dev->hard_header =3D p80211_header; DS> dev->rebuild_header =3D p80211_rebuild_header; DS> DS> Your merely changing the tab character after dev->hard_header DS> into spaces. Please don't do this. This makes a lot of white DS> space noise when making diffs against the original davem-p80211 DS> code thus making it harder to review the changes you actually made. My editor did it for me. I'll be more carefull to check this behind the sce= ne=20 things. Maybe, I'll do one patch to do all spaces accordingly to kernel=20 coding style, and since that will follow it. DS> DS> Next: DS> DS> + dev->mtu =3D 2304; DS> + dev->type =3D ARPHRD_IEEE80211; DS> DS> Is this really the correct default MTU for wireless devices? Yes, 802.11e (QoS) defines this value. DS> DS> @@ -342,7 +343,7 @@ int p80211_recv_cfackpoll(struct sk_buff DS> static struct packet_type p80211_packet_type =3D { DS> .type =3D __constant_htons(ETH_P_802_11), DS> .func =3D p80211_rcv, DS> - .data =3D (void *) 1, /* understands shared SKBs */ DS> + .af_packet_priv =3D (void *) 1, /* understands shared SKBs */ DS> }; DS> DS> You can just remove this line entirely for 2.6.x kernels. Thanks, I will. I was confused by this member and did simplest trick to mak= e=20 it compile. DS> DS> Otherwise looks fine :-) Really, thus far I did almost nothing. It is just foundation for playing wi= th=20 stack. My intention was to decouple driver and stack ASAP to enable separat= e=20 development for each part. Next step I will do data path, with some code to enable QoS 26 byte headers= =20 but without real QoS, which is, by the way, pretty complicated as defined i= n=20 TGe. May be, it is better to start with WME w.r.t QoS. Then, it is management's turn. Association, scanning. Then, once again, data path. Fragmentation, reassembly. Framework for=20 security. Then - let's see how this will develop. --nextPart6206511.VO1UjDSxoh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBXed0qxdj7mhC6o0RAo7iAJ0QM7tZtzzcVIKzG1GDm2h3iQbcsgCfdP06 k+A04teh0Hj/6vwDpiOZR8c= =53Am -----END PGP SIGNATURE----- --nextPart6206511.VO1UjDSxoh-- From davem@davemloft.net Fri Oct 1 17:06:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 17:06:44 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9206dfY012457 for ; Fri, 1 Oct 2004 17:06:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDXOS-0008Il-00; Fri, 01 Oct 2004 17:04:56 -0700 Date: Fri, 1 Oct 2004 17:04:56 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, netdev@oss.sgi.com, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Re: Current 2.6.x TSO state Message-Id: <20041001170456.3ec52222.davem@davemloft.net> In-Reply-To: <20041001231939.GC23046@wotan.suse.de> References: <20040930213221.06a3f5b3.davem@davemloft.net> <20041001121123.19511403.ak@suse.de> <20041001124733.1ac4266a.davem@davemloft.net> <20041001195146.GA23046@wotan.suse.de> <20041001125643.30c6830f.davem@davemloft.net> <20041001231939.GC23046@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 2 Oct 2004 01:19:39 +0200 Andi Kleen wrote: > > As mentioned, the TCP receive buffer auto-tuning takes care > > of all of this in 2.6.6 and later. It's just 2.6.5 doesn't > > How do you explain the 2-4MB/s less with manually increased > receive buffers? Some scheduling differences, I suppose. Frankly, I've done what I can with the TSO stuff at this point. All I get from you are "it's slower" and no code, I've had to write and fix and debug everything for you. The performance is close or on-par to non-TSO and more importantly TSO abides by the congestion window and MSS values properly now. That's 10 times more important than 2-4MB/s performance difference. Or maybe I should revert all of the TSO work so that all SpecWEB submissions done with 2.6.x kernels get invalidated? From davem@davemloft.net Fri Oct 1 17:13:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 17:13:45 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i920DdTJ012845 for ; Fri, 1 Oct 2004 17:13:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDXVG-0008Jj-00; Fri, 01 Oct 2004 17:11:58 -0700 Date: Fri, 1 Oct 2004 17:11:58 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, mcgrof@studorgs.rutgers.edu, acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org Subject: Re: generic 802.11 stack Message-Id: <20041001171158.489e3cf1.davem@davemloft.net> In-Reply-To: <200410020125.40669.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200410011630.59465.vkondra@mail.ru> <20041001155310.515ee09e.davem@davemloft.net> <200410020125.40669.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 2 Oct 2004 01:25:32 +0200 Vladimir Kondratiev wrote: > DS> Next: > DS> > DS> + dev->mtu = 2304; > DS> + dev->type = ARPHRD_IEEE80211; > DS> > DS> Is this really the correct default MTU for wireless devices? > > Yes, 802.11e (QoS) defines this value. All existing wireless drivers use the standard ethernet MTU. I really think it is supposed to be 1500. That's why I left it at ether_setup()'s setting. Upper layers really want to see a 1500 byte standard ethernet MTU by default. It's OK to let people set this higher via netdev->change_mtu() configuration calls, but by default it should be something that makes sense for most networks and that is 1500. Yes, btw, your tabs are all screwed up. Please configure your editor to use real tab characters. Your's is using spaces and using a tab-stop of 4 when it should be 8. From jheffner@psc.edu Fri Oct 1 18:32:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 18:32:46 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i921WeH4013997 for ; Fri, 1 Oct 2004 18:32:41 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i921WP30006051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Oct 2004 21:32:26 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i921WPCW026692; Fri, 1 Oct 2004 21:32:25 -0400 (EDT) Date: Fri, 1 Oct 2004 21:32:25 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer1.psc.edu X-Virus-Status: Clean X-archive-position: 9793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev > On Thu, 30 Sep 2004, David S. Miller wrote: > > > Please help debug this John since I'm not seeing this here. Here's what I've observed now: on one machine I have interface hangs after a non-deterministic amount of time (usually within a few seconds) with TSO on if I'm sending at a reasonably high rate with a 1500 byte MTU. I get no hangs with a 9000 byte mtu, or at a low rate (sending to a FastE host). Interestingly, if the interface mtu is 9000, but I'm sending 1500 byte packets, it does not seem to hang. On a different machine (both P4's with e1000's) I get no hangs. The hangs happen even with 2.6.8.1 before the recent TSO changes, so it's not a bug there. I looked at some tcpdumps and saw no strangeness in the last segments sent. The good machine has an e7500 chipset and a 82544EI. The bad machine has a ServerWorks chipset and a 82545GM. Any suggestions on where to look for what's going wrong with the interface? Thanks, -John From herbert@gondor.apana.org.au Fri Oct 1 22:02:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 22:03:03 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9252pEg020353 for ; Fri, 1 Oct 2004 22:02:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CDc2O-0003R0-00; Sat, 02 Oct 2004 15:02:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CDc2I-0003wP-00; Sat, 02 Oct 2004 15:02:22 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [PATCH]: fixed typo of reassembly.c Cc: yasuyuki.kozakai@toshiba.co.jp, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Organization: Core In-Reply-To: <20041001151923.261b42b3.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 02 Oct 2004 15:02:22 +1000 X-archive-position: 9794 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 David S. Miller wrote: > > It is textual fix only, do you realize this? > Both ntohs() and htons() perform the same transformation > on a 16-bit data item. It really does not matter which > one you actually use, in practice. It might make a difference in future if the sparse people decide to annotate its arguments/return values. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Fri Oct 1 23:40:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Oct 2004 23:40:39 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i926eWJu022688 for ; Fri, 1 Oct 2004 23:40:33 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDdXN-00006x-00; Fri, 01 Oct 2004 23:38:33 -0700 Date: Fri, 1 Oct 2004 23:38:32 -0700 From: "David S. Miller" To: Herbert Xu Cc: yasuyuki.kozakai@toshiba.co.jp, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [PATCH]: fixed typo of reassembly.c Message-Id: <20041001233832.34bd0a91.davem@davemloft.net> In-Reply-To: References: <20041001151923.261b42b3.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 02 Oct 2004 15:02:22 +1000 Herbert Xu wrote: > David S. Miller wrote: > > > > It is textual fix only, do you realize this? > > Both ntohs() and htons() perform the same transformation > > on a 16-bit data item. It really does not matter which > > one you actually use, in practice. > > It might make a difference in future if the sparse people decide to > annotate its arguments/return values. That's true. Al Viro has done this on the filesystems and "cpu_to_{be,le}{16,32,64}()" et al. interfaces. I'm sure he'll hit the networking before long. From herbert@gondor.apana.org.au Sat Oct 2 00:51:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 00:51:40 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i927pUVD027127 for ; Sat, 2 Oct 2004 00:51:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CDefX-0003yy-00; Sat, 02 Oct 2004 17:51:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CDefL-0004hQ-00; Sat, 02 Oct 2004 17:50:51 +1000 Date: Sat, 2 Oct 2004 17:50:51 +1000 To: "David S. Miller" Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20041002075051.GA18037@gondor.apana.org.au> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927111520.4f495b17.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20040927111520.4f495b17.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 27, 2004 at 11:15:20AM -0700, David S. Miller wrote: > On Mon, 27 Sep 2004 21:48:33 +1000 > Herbert Xu wrote: > > > > - if (tbl->entries > (tbl->hash_mask + 1)) > > > + if (tbl->entries > (tbl->hash_mask + 1)) { > > > + write_lock_bh(&tbl->lock); > > > neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); > > > + write_unlock_bh(&tbl->lock); > > > + } > > > > The locking should be outside the if block as otherwise you may grow > > unnecessarily or grow into the same size :) > > I'm not going to do that, because then we're grabbing that lock > twice on every neigh create operation and I was trying hard > to avoid that overhead. Actually, why don't we just move the expansion into the locked section? Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/core/neighbour.c 1.51 vs edited ===== --- 1.51/net/core/neighbour.c 2004-10-02 07:58:21 +10:00 +++ edited/net/core/neighbour.c 2004-10-02 17:47:11 +10:00 @@ -406,12 +406,6 @@ goto out; } - if (tbl->entries > (tbl->hash_mask + 1)) { - write_lock_bh(&tbl->lock); - neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); - write_unlock_bh(&tbl->lock); - } - memcpy(n->primary_key, pkey, key_len); n->dev = dev; dev_hold(dev); @@ -432,6 +426,9 @@ n->confirmed = jiffies - (n->parms->base_reachable_time << 1); write_lock_bh(&tbl->lock); + + if (tbl->entries > (tbl->hash_mask + 1)) { + neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); hash_val = tbl->hash(pkey, dev) & tbl->hash_mask; --PNTmBPCT7hxwcZjr-- From duncan.sands@math.u-psud.fr Sat Oct 2 01:17:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 01:17:46 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i928Hd0s027878 for ; Sat, 2 Oct 2004 01:17:40 -0700 Received: from pbaldrick.hd.free.fr (massena-4-82-67-197-146.fbx.proxad.net [82.67.197.146]) by postfix4-2.free.fr (Postfix) with ESMTP id 2FEA820F423; Sat, 2 Oct 2004 10:17:26 +0200 (CEST) Received: by pbaldrick.hd.free.fr (Postfix, from userid 500) id 1D7F8A8728; Sat, 2 Oct 2004 09:58:02 +0200 (CEST) From: Duncan Sands To: "David S. Miller" Subject: Re: Oops at __neigh_for_each_release (2.6.9-rc3) Date: Sat, 2 Oct 2004 09:58:00 +0200 User-Agent: KMail/1.6.2 Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, laforge@gnumonks.org References: <200410012217.35264.baldrick@free.fr> <20041001135636.0c071602.davem@davemloft.net> In-Reply-To: <20041001135636.0c071602.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410020958.01197.baldrick@free.fr> X-archive-position: 9797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baldrick@free.fr Precedence: bulk X-list: netdev > > EIP is at __neigh_for_each_release+0x32/0xb0 > > Give this patch a try. And please report networking bugs > to netdev@oss.sgi.com in the future, thanks. OK, will do. I tested the patch Linus committed - it indeed fixes the oops. Thanks a lot! Duncan. From margitsw@t-online.de Sat Oct 2 02:26:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 02:26:47 -0700 (PDT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i929Qeb4029197 for ; Sat, 2 Oct 2004 02:26:41 -0700 Received: from fwd09.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1CDg9l-0000Q8-01; Sat, 02 Oct 2004 11:26:21 +0200 Received: from margit.t-online.de (XdwFZZZSwegAYW0xWWI8kv7S+wRqQhro5aZnpGSy2fu0RZvqO8wprh@[217.226.116.15]) by fwd09.sul.t-online.com with esmtp id 1CDg9f-29F1H60; Sat, 2 Oct 2004 11:26:15 +0200 Message-Id: <5.1.0.14.2.20041002105713.026705d8@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Oct 2004 11:07:18 +0200 To: Greg KH From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: [Kernel-janitors] Re: [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() Cc: jgarzik@pobox.com, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org, mcgrof@studorgs.rutgers.edu, prism54-devel@prism54.org, hvr@gnu.org In-Reply-To: <20041001165523.GC11646@kroah.com> References: <5.1.0.14.2.20041001084419.02570b18@pop.t-online.de> <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> <20040923221303.GB13244@us.ibm.com> <20040923221303.GB13244@us.ibm.com> <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> <5.1.0.14.2.20041001084419.02570b18@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ID: XdwFZZZSwegAYW0xWWI8kv7S+wRqQhro5aZnpGSy2fu0RZvqO8wprh X-TOI-MSGID: 985859d3-d2bd-4320-99fa-e11d875a8fbf X-archive-position: 9798 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 At 09:55 01.10.2004 -0700, Greg scribeth: >On Fri, Oct 01, 2004 at 09:04:27AM +0200, Margit Schubert-While wrote: > > At 00:15 01.10.2004 -0400, Jeff scribeth: > > >I would rather see an msleep implementation in 2.4.x... > > > > Hear, hear. > > And can we PLEASE have a > > "#define HAVE_MSLEEP" in delay.h ?!!! > > (2.4. AND 2.6) > >No, this is not how the kernel source tree works, sorry. Well it happened with netdev_priv ;-) (HAVE_NETDEV_PRIV) Margit From yoshfuji@linux-ipv6.org Sat Oct 2 03:31:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 03:31:36 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i92AVTTN001590 for ; Sat, 2 Oct 2004 03:31:30 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A6C3833CE5; Sat, 2 Oct 2004 19:31:38 +0900 (JST) Date: Sat, 02 Oct 2004 19:31:38 +0900 (JST) Message-Id: <20041002.193138.94763422.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH 2.6] [IPV6] SIT: dst leakage in error path. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. We failed to put rt in error path. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/sit.c 1.41 vs edited ===== --- 1.41/net/ipv6/sit.c 2004-09-17 05:10:00 +09:00 +++ edited/net/ipv6/sit.c 2004-10-02 19:24:05 +09:00 @@ -487,6 +487,7 @@ } } if (rt->rt_type != RTN_UNICAST) { + ip_rt_put(rt); tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Sat Oct 2 03:34:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 03:34:20 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i92AYFGi001956 for ; Sat, 2 Oct 2004 03:34:15 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1BF2633CE5; Sat, 2 Oct 2004 19:34:25 +0900 (JST) Date: Sat, 02 Oct 2004 19:34:24 +0900 (JST) Message-Id: <20041002.193424.76694251.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6] [IPV6] SIT: dst leakage in error path. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20041002.193138.94763422.yoshfuji@linux-ipv6.org> References: <20041002.193138.94763422.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 9800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20041002.193138.94763422.yoshfuji@linux-ipv6.org> (at Sat, 02 Oct 2004 19:31:38 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > We failed to put rt in error path. > > Signed-off-by: Hideaki YOSHIFUJI And this also applies 2.4 (with some fuzz). --yoshfuji From benh@kernel.crashing.org Sat Oct 2 04:54:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 04:54:46 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i92BsdUr006897 for ; Sat, 2 Oct 2004 04:54:40 -0700 Received: from localhost (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id i92BlOKM010068; Sat, 2 Oct 2004 06:47:26 -0500 Subject: Re: kernel crash with G5 Xserve and sungem driver From: Benjamin Herrenschmidt To: Harald Welte Cc: Chris Friesen , netdev@oss.sgi.com, linuxppc-dev@ozlabs.org In-Reply-To: <20041001194630.GO27499@sunbeam.de.gnumonks.org> References: <415D8768.8080808@nortelnetworks.com> <20041001193153.GN27499@sunbeam.de.gnumonks.org> <415DB334.4010809@nortelnetworks.com> <20041001194630.GO27499@sunbeam.de.gnumonks.org> Content-Type: text/plain Message-Id: <1096717811.3634.45.camel@gaston> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 02 Oct 2004 21:50:11 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 9801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: benh@kernel.crashing.org Precedence: bulk X-list: netdev On Sat, 2004-10-02 at 05:46, Harald Welte wrote: > On Fri, Oct 01, 2004 at 01:42:44PM -0600, Chris Friesen wrote: > > Harald Welte wrote: > > > > >Just don't compile (or load) the sungem driver on those boxes. > > > > Hmm. That's a pain. We've got G5 desktops too, and it would be nice to be > > able to run one kernel for both. It'd be better (IMHO) to fix the driver > > so it doesn't crash. > > I recommend talking to Bejamin Herrenschmidt, IIRC he already had > something in mind in order to fix the issue. > > I mean, you can always hardcode some exemption into the driver, that's > two easy lines ;) Or just have the driver test the return value of pci_device_to_OF_node() for NULL :) One thing is that I'm about to push a patch that will "hide" PCI devices from the kernel that are absent from the OF tree since there are other issues with newer machines, so that will fix the problem. Both 64 bits and 32 bits patches are below: ===== arch/ppc64/kernel/pmac_pci.c 1.5 vs edited ===== --- 1.5/arch/ppc64/kernel/pmac_pci.c 2004-07-25 14:51:52 +10:00 +++ edited/arch/ppc64/kernel/pmac_pci.c 2004-08-04 10:26:07 +10:00 @@ -271,7 +271,7 @@ int offset, int len, u32 *val) { struct pci_controller *hose; - struct device_node *busdn; + struct device_node *busdn, *dn; unsigned long addr; if (bus->self) @@ -282,6 +282,16 @@ return PCIBIOS_DEVICE_NOT_FOUND; hose = busdn->phb; if (hose == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; + + /* We only allow config cycles to devices that are in OF device-tree + * as we are apparently having some weird things going on with some + * revs of K2 on recent G5s + */ + for (dn = busdn->child; dn; dn = dn->sibling) + if (dn->devfn == devfn) + break; + if (dn == NULL) return PCIBIOS_DEVICE_NOT_FOUND; addr = u3_ht_cfg_access(hose, bus->number, devfn, offset); ===== arch/ppc/platforms/pmac_pci.c 1.21 vs edited ===== --- 1.21/arch/ppc/platforms/pmac_pci.c 2004-07-29 14:58:35 +10:00 +++ edited/arch/ppc/platforms/pmac_pci.c 2004-08-17 14:18:09 +10:00 @@ -315,6 +315,10 @@ unsigned int addr; int i; + struct device_node *np = pci_busdev_to_OF_node(bus, devfn); + if (np == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; + /* * When a device in K2 is powered down, we die on config * cycle accesses. Fix that here. @@ -362,6 +366,9 @@ unsigned int addr; int i; + struct device_node *np = pci_busdev_to_OF_node(bus, devfn); + if (np == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; /* * When a device in K2 is powered down, we die on config * cycle accesses. Fix that here. From margitsw@t-online.de Sat Oct 2 07:48:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 07:48:54 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i92EmnEe009380 for ; Sat, 2 Oct 2004 07:48:49 -0700 Received: from fwd08.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1CDlBa-0008IN-00; Sat, 02 Oct 2004 16:48:34 +0200 Received: from roglap.local (XRIpreZ-ZeuSY3MYmmmLhklyopvTlIR65EeJl4mHH73oPHF-F2fmcm@[80.128.222.170]) by fwd08.sul.t-online.com with esmtp id 1CDlBN-27CFjE0; Sat, 2 Oct 2004 16:48:21 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 0/4 linux-2.6.9-rc3/linux-2.4.28-pre3] prism54 bugs/patches Date: Sat, 2 Oct 2004 16:34:56 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410021634.56857.margitsw@t-online.de> X-ID: XRIpreZ-ZeuSY3MYmmmLhklyopvTlIR65EeJl4mHH73oPHF-F2fmcm X-TOI-MSGID: 49f6f2a3-5fec-4188-8eb3-419d470f2f21 X-archive-position: 9802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev 2004-10-02 Margit Schubert-While * 01_remtrace.patch * Remove TRACE to please the janitors * 02_schedbug.patch * Bug in loop around schedule_timeout * We must rearm the task * * Make timeout message meaningful * 03_fwprint.patch * Print firmware version * * As per convention, make errno return negative * 04_mgtcommit.patch * Change mgt_commit from void to int * We call this from device initialization, * therefore we need to know that it has succeeded * If it hasn't, we do not have a working device and * should pass a non-zero value upwards Jeff, as usual, applies to both 2.4 and 2.6; however, there are outstanding patches for 2.4. Margit From margitsw@t-online.de Sat Oct 2 07:53:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Oct 2004 07:53:43 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i92Erc6U009726 for ; Sat, 2 Oct 2004 07:53:39 -0700 Received: from fwd07.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1CDlGG-0005An-02; Sat, 02 Oct 2004 16:53:24 +0200 Received: from roglap.local (X7jIUUZfoejiSTCM5XlTGmrOL-+j9sTYPtAidfQlhR6oZ2gkDLznEC@[80.128.222.170]) by fwd07.sul.t-online.com with esmtp id 1CDlG5-1W5CTI0; Sat, 2 Oct 2004 16:53:13 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 1/4 linux-2.6.9-rc3/linux-2.4.28-pre3] prism54 remove TRACE Date: Sat, 2 Oct 2004 16:39:48 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_02rXBe1fWCdgDwu" Message-Id: <200410021639.48960.margitsw@t-online.de> X-ID: X7jIUUZfoejiSTCM5XlTGmrOL-+j9sTYPtAidfQlhR6oZ2gkDLznEC X-TOI-MSGID: cd1c3969-4a6b-45e5-9ce3-7ae019fe5059 X-archive-position: 9803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_02rXBe1fWCdgDwu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-10-02 Margit Schubert-While * 01_remtrace.patch * Remove TRACE to please the janitors Margit --Boundary-00=_02rXBe1fWCdgDwu Content-Type: text/x-diff; charset="us-ascii"; name="01_remtrace.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="01_remtrace.patch" diff -Naur linux-2.6.9rc2/drivers/net/wire